Re: Cyrus Imap and Automake
Ondřej Surý wrote: On Wed, Aug 3, 2011 at 17:59, Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: Thomas Jarosch wrote: Hi Дилян, here's some feedback about your build system question. Note: I'm not one of the cyrus core developers. if I rewrite the build system of Cyrus imap 2.4(.10) to use Automake to generate the Makefile.in-files, will the patch be accepted in reasonable time in git/master? Have you considered alternatives to GNU Autotools? We have experience with GNU Autotools in our company projects as well as open source projects for several years now. We have found that it has several shortcomings: 1. Autotools version conflicts You can compile a released source package without any Autotools on your system. But as soon as you a) want to develop b) want to install a patch which modifies the build system (like a new path to a library, something that adds a new file,...). This is often happens as part of packaging for .rpm or .deb. you need Autotools on your machine. If the Autotools version on your machine and the one used to build the release are not compatible you can't build. Installing a different Autotools version on a given distribution without breaking something or fixing a huge list of dependency problems is nearly impossible. I have experience with this... I have quite the experience with .rpm and .deb building myself as well, and while I agree autotools *can* be problematic at times, I recon the Linux distributions are not the biggest of problems - the culprit, I think, is with the number of custom / site-specific builds out there, ranging from Sun Solaris to FreeBSD and who knows what versions of autotools are on these systems. With my fancy debian maintainer hat on - I agree, we learnt how to cope with different versions of autotools, that's the minor thing. I personally I would love to have cyrus projects automakized. It's much easy to mangle :). Between the two of us, Debian and Fedora maintainers, are we both saying yes please, no objections? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: Cyrus Imap and Automake
On Wed, Jul 27, 2011 at 03:58:53PM +0200, ?? wrote: if I rewrite the build system of Cyrus imap 2.4(.10) to use Automake to generate the Makefile.in-files, will the patch be accepted in reasonable time in git/master? Sadly this thread seems to have degenerated again - I think the above question is extremely valid. It takes effort to write such patches, and it is a shame when they sit in bugzilla etc. Hoping for a yes please! from a commiter... Cheers, Patrick
Re: Cyrus Imap and Automake
On Wed, Aug 3, 2011 at 17:59, Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: Thomas Jarosch wrote: Hi Дилян, here's some feedback about your build system question. Note: I'm not one of the cyrus core developers. if I rewrite the build system of Cyrus imap 2.4(.10) to use Automake to generate the Makefile.in-files, will the patch be accepted in reasonable time in git/master? Have you considered alternatives to GNU Autotools? We have experience with GNU Autotools in our company projects as well as open source projects for several years now. We have found that it has several shortcomings: 1. Autotools version conflicts You can compile a released source package without any Autotools on your system. But as soon as you a) want to develop b) want to install a patch which modifies the build system (like a new path to a library, something that adds a new file,...). This is often happens as part of packaging for .rpm or .deb. you need Autotools on your machine. If the Autotools version on your machine and the one used to build the release are not compatible you can't build. Installing a different Autotools version on a given distribution without breaking something or fixing a huge list of dependency problems is nearly impossible. I have experience with this... I have quite the experience with .rpm and .deb building myself as well, and while I agree autotools *can* be problematic at times, I recon the Linux distributions are not the biggest of problems - the culprit, I think, is with the number of custom / site-specific builds out there, ranging from Sun Solaris to FreeBSD and who knows what versions of autotools are on these systems. With my fancy debian maintainer hat on - I agree, we learnt how to cope with different versions of autotools, that's the minor thing. I personally I would love to have cyrus projects automakized. It's much easy to mangle :). O. -- Ondřej Surý ond...@sury.org
Re: Cyrus Imap and Automake
Hi Дилян, here's some feedback about your build system question. Note: I'm not one of the cyrus core developers. if I rewrite the build system of Cyrus imap 2.4(.10) to use Automake to generate the Makefile.in-files, will the patch be accepted in reasonable time in git/master? Have you considered alternatives to GNU Autotools? We have experience with GNU Autotools in our company projects as well as open source projects for several years now. We have found that it has several shortcomings: 1. Autotools version conflicts You can compile a released source package without any Autotools on your system. But as soon as you a) want to develop b) want to install a patch which modifies the build system (like a new path to a library, something that adds a new file,...). This is often happens as part of packaging for .rpm or .deb. you need Autotools on your machine. If the Autotools version on your machine and the one used to build the release are not compatible you can't build. Installing a different Autotools version on a given distribution without breaking something or fixing a huge list of dependency problems is nearly impossible. I have experience with this... 2. Build speed and parallelization The configure run can't be run on multiple cpu cores at once and is usually slow. Running compile jobs on multiple cores at once can become tricky if you have internal dependencies like libs that are included in your project. Sometimes we experienced race conditions or cases where you had to start the build process two or three times to get a successful build. 3. Documentation and learning There is a book about Autotools (http://sourceware.org/autobook/). I have read it and don't think that it explains how to use and troubleshoot Autotools in a good way. Maybe it's hard to explain because in Autotools everything is a macro that calls a macro that calls a macro... I think the learning curve of Autotools is very steep and finding out what's really happening during troubleshooting is very time consuming. Because of these shortcomings we have used CMake for new projects for about a year. We have made good experience with it. We have now started to port all Autotools projects over to CMake. Please take a look at CMake and consider it before you start investing time into Autotools. Best regards, Thomas
Re: Cyrus Imap and Automake
Hello Thomas, Thanks for your feedback. My idea is to improve the current build system by generating the Makefile(s).in by automake. I have some experience with Autotools. I have absolutely nothing against CMake or other build systems, except I have no coding experience with them. If you think that CMake is more suitable than Autotools, if somebody wants to change the build system to make use of CMake and if there are no objections for cyrus imapd + CMake, then I have no problems with CMake. Parallelization race conditions will be avoided by having a single Makefile.in for all subdirectories. Със здраве Дилян Please take a look at CMake and consider it before you start investing time into Autotools. That is why I posted the question before starting. On 29.07.2011 18:14, Thomas Jarosch wrote: Hi Дилян, here's some feedback about your build system question. Note: I'm not one of the cyrus core developers. if I rewrite the build system of Cyrus imap 2.4(.10) to use Automake to generate the Makefile.in-files, will the patch be accepted in reasonable time in git/master? Have you considered alternatives to GNU Autotools? We have experience with GNU Autotools in our company projects as well as open source projects for several years now. We have found that it has several shortcomings: 1. Autotools version conflicts You can compile a released source package without any Autotools on your system. But as soon as you a) want to develop b) want to install a patch which modifies the build system (like a new path to a library, something that adds a new file,...). This is often happens as part of packaging for .rpm or .deb. you need Autotools on your machine. If the Autotools version on your machine and the one used to build the release are not compatible you can't build. Installing a different Autotools version on a given distribution without breaking something or fixing a huge list of dependency problems is nearly impossible. I have experience with this... 2. Build speed and parallelization The configure run can't be run on multiple cpu cores at once and is usually slow. Running compile jobs on multiple cores at once can become tricky if you have internal dependencies like libs that are included in your project. Sometimes we experienced race conditions or cases where you had to start the build process two or three times to get a successful build. 3. Documentation and learning There is a book about Autotools (http://sourceware.org/autobook/). I have read it and don't think that it explains how to use and troubleshoot Autotools in a good way. Maybe it's hard to explain because in Autotools everything is a macro that calls a macro that calls a macro... I think the learning curve of Autotools is very steep and finding out what's really happening during troubleshooting is very time consuming. Because of these shortcomings we have used CMake for new projects for about a year. We have made good experience with it. We have now started to port all Autotools projects over to CMake. Please take a look at CMake and consider it before you start investing time into Autotools. Best regards, Thomas
Re: Cyrus Imap and Automake
Sent from my iPhone On 30/07/2011, at 5:48, Дилян Палаузов dilyan.palau...@aegee.org wrote: I have some experience with Autotools. I have absolutely nothing against CMake or other build systems, except I have no coding experience with them. Me too :( In my experience autotools can be convinced, with sufficient blunt force, to do most things. I don't doubt that better tools exist, but autotools is the lingua franca. Greg.
