Cyrus Imap and Automake

Дилян Палаузов dilyan.palauzov at aegee.org
Fri Jul 29 15:48:41 EDT 2011


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


More information about the Cyrus-devel mailing list