At the moment p7zip isn't using the gnu autotools (autoconf/automake/libtool) that lead to the nice "./configure ; make ; make install" routine found with many open source projects, and instead p7zip ships many different makefiles.
Using GNU autotools offers many benefits, such as DESTDIR which allows installation to a prototype directory, which many packaging systems make use of for packaging up software.
I was wondering if the project would be open to converting the build system to autoconf?
I can do a basic autoconf config and test this on Linux x86/amd64, Solaris x86/amd64, and MacOS 10.6 intel. I can probably get hold of a FreeBSD box, but I don't have access to aix, beos, cygwin, hpux, netbsd, openbsd, qnx, or any fruity processors.
Let me know if there is interest in this.
Cheers,
Alasdair
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I maintain the OpenBSD port. Our port has some customizations and a patch which are not upstream here because the OS's ports and packaging infrastructure is not used during p7zip development or deployment. See the Makefile and patch directory at http://www.openbsd.org/cgi-bin/cvsweb/ports/archivers/p7zip/
There has been no interest in integrating these into p7zip.
That said, ……. WHICH autoconf were you thinking of using? Our ports tree has to keep more than a dozen versions as they are not interoperable. You might be replacing one build coven with another.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply. I was hoping specifically to use the standard GNU autoconf (2.68), automake, (1.11), and libtool (2.4), so that for 99% of users, they just "wget http://…/pzip-x.x.tar.gz ; tar -zxf pzip-x.x.tar.gz ; cd pzip-x.x ; ./configure ; make ; make install".
Although most OS distributions will plonk p7zip inside their standard build framework, there will be lots of users downloading the source who want to quickly build p7zip without resorting to hacking makefiles. I actually had to integrate p7zip into our build framework at work for Solaris 10, and thats when I decided p7zip could really benefit from being autoconfed.
But before I do the work, it'd be nice to know the project devs would actually integrate the changes.
aff - regarding cmake, unfortunately I don't have time to learn another build system. Most GNU projects use autoconf/automake/libtool, as well as major projects like Apache httpd, PHP, etc. I know MySQL switched to cmake, however I'd like to stick with autoconf as I doubt p7zip's build requirements are as complex as MySQL.
Cheers,
Alasdair
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wanted to use autoconf tools to build p7zip.
But when I read the autoconf tutorials/docs I was afraid of the complexity.
I read some autoconf files for some projects and these files were complex to support a lot of platforms…
As I understood, the autoconf files must be tweaked /tuned for each platform that p7zip supports.
As I don't have acces to all platforms that p7zip can run, I will not be able to test the autoconf files for each platforms.
But I think that "./configure -prefix=${HOME}/try/ ; make ; make install" is really cool.
p7zip must find :
- if some headers (wchar.h, …) are available (see CPP/myWindows/config.h)
- if some functions are available (see CPP/myWindows/config.h)
The functions needed :
- threading (pthread or BeOs)
- Unicode (wchar_t, …)
- wxWidgets (for the GUI parts of p7zip)
I already have CMAKE, PREMAKE (not really used) and QMAKE (only 7za program) projects in CPP/7zip.
With CMAKE, I can make a xcode project for MacOSX.
With QMAKE, I can use the very good qtcreator IDE.
Remark 1 : the p7zip package managers for each Linux distributions don't complain about my "odd" building process …
Remark 2 : I don't have time to support myself each package format (deb, rpm, portage, …).
Remark 3 : the source tree of p7zip (7-zip) does not follow the source tree of a good autoconf project …
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi There,
At the moment p7zip isn't using the gnu autotools (autoconf/automake/libtool) that lead to the nice "./configure ; make ; make install" routine found with many open source projects, and instead p7zip ships many different makefiles.
Using GNU autotools offers many benefits, such as DESTDIR which allows installation to a prototype directory, which many packaging systems make use of for packaging up software.
I was wondering if the project would be open to converting the build system to autoconf?
I can do a basic autoconf config and test this on Linux x86/amd64, Solaris x86/amd64, and MacOS 10.6 intel. I can probably get hold of a FreeBSD box, but I don't have access to aix, beos, cygwin, hpux, netbsd, openbsd, qnx, or any fruity processors.
Let me know if there is interest in this.
Cheers,
Alasdair
I maintain the OpenBSD port. Our port has some customizations and a patch which are not upstream here because the OS's ports and packaging infrastructure is not used during p7zip development or deployment. See the Makefile and patch directory at http://www.openbsd.org/cgi-bin/cvsweb/ports/archivers/p7zip/
There has been no interest in integrating these into p7zip.
That said, ……. WHICH autoconf were you thinking of using? Our ports tree has to keep more than a dozen versions as they are not interoperable. You might be replacing one build coven with another.
Coven = concern. Damned smartphone.
Consider cmake as well.
Hi jggimi,
Thanks for the reply. I was hoping specifically to use the standard GNU autoconf (2.68), automake, (1.11), and libtool (2.4), so that for 99% of users, they just "wget http://…/pzip-x.x.tar.gz ; tar -zxf pzip-x.x.tar.gz ; cd pzip-x.x ; ./configure ; make ; make install".
Although most OS distributions will plonk p7zip inside their standard build framework, there will be lots of users downloading the source who want to quickly build p7zip without resorting to hacking makefiles. I actually had to integrate p7zip into our build framework at work for Solaris 10, and thats when I decided p7zip could really benefit from being autoconfed.
But before I do the work, it'd be nice to know the project devs would actually integrate the changes.
aff - regarding cmake, unfortunately I don't have time to learn another build system. Most GNU projects use autoconf/automake/libtool, as well as major projects like Apache httpd, PHP, etc. I know MySQL switched to cmake, however I'd like to stick with autoconf as I doubt p7zip's build requirements are as complex as MySQL.
Cheers,
Alasdair
Hello,
I wanted to use autoconf tools to build p7zip.
But when I read the autoconf tutorials/docs I was afraid of the complexity.
I read some autoconf files for some projects and these files were complex to support a lot of platforms…
As I understood, the autoconf files must be tweaked /tuned for each platform that p7zip supports.
As I don't have acces to all platforms that p7zip can run, I will not be able to test the autoconf files for each platforms.
But I think that "./configure -prefix=${HOME}/try/ ; make ; make install" is really cool.
p7zip must find :
- if some headers (wchar.h, …) are available (see CPP/myWindows/config.h)
- if some functions are available (see CPP/myWindows/config.h)
The functions needed :
- threading (pthread or BeOs)
- Unicode (wchar_t, …)
- wxWidgets (for the GUI parts of p7zip)
I already have CMAKE, PREMAKE (not really used) and QMAKE (only 7za program) projects in CPP/7zip.
With CMAKE, I can make a xcode project for MacOSX.
With QMAKE, I can use the very good qtcreator IDE.
Remark 1 : the p7zip package managers for each Linux distributions don't complain about my "odd" building process …
Remark 2 : I don't have time to support myself each package format (deb, rpm, portage, …).
Remark 3 : the source tree of p7zip (7-zip) does not follow the source tree of a good autoconf project …