Die GNU autotools

[Shlomi Fish]

On Monday 10 Jan 2011 15:51:10 Shachar Shemesh wrote:
> On 10/01/11 15:09, Nadav Har'El wrote:
> > Things like Cmake
> > and Adon-Banai can hardly be considered replacements to Autoconf -
> > perhaps they are better "make", perhaps they are "imake done again", but
> > not "better than autoconf".
> 
> I tried, twice, in the past to poke people who were recommending CMake
> on these points. To date, I have not managed to receive any satisfactory
> answers.

Actually, CMake is not "imake done right", but actually is a better Autoconf. 
One can write build-time tests with it to test for features and configure the 
build accordingly, just like you can with Autoconf, only in a cleaner and 
easier and less problem-causing way. I don't know about "Adon-Banai". 

> 
> The way I see it, from the somewhat limited research I've done:
> 
> autoconf: More or less like Nadav put it. A vital tool (with it's should
> be mandatory friend, autoheader, of course) for cross-platform posix
> code. Need to use O_NOFOLLOW, but only some platforms have it? Write a
> tiny test, define O_NOFOLLOW to zero if the test fails, and you're done.
> No need to check anything in the source code. No #ifdefs. Also, many
> people who do not like autoconf have simply never heard of autoscan.
> 

Autoconf, aclocal, acinclude, autoscan, autoheader, libtool, intltool, 
automake, and lots of other technologies in a complex dependency graph:

http://www.shlomifish.org/lecture/Autotools/slides/how_it_fits.html

Excuse me if I faint.

> Automake: I actually use it, and quite like it. It gives a strange but
> useful balance between the straitjacket that is any makefile generator
> and does leave some space for actual customization, if you care enough
> to learn the idiosyncrasies. I do not use it for all my projects, and
> even when I do use it, I do not always use it for ALL of the project
> (check out fakeroot-ng for a project that uses automake for some, but
> not all, of the build process), but where I do use it, I find it does a
> decent job of it. The main advantage, as far as I'm concerned, is that
> all it requires from the destination platform is a functioning bourne
> shell.

Automake was kinda quirky, last time I tried and has problems with backwards 
compatibility and forward-compatibility. The CMake makefile generation is much 
cleaner.

> 
> m4/aclocal - I use it as part of the autoconf generation, but have never
> bothered to learn it properly.

m4 is very vile.

> 
> libtool - there's a loaded subject. Yes, I usually use it, but no, I
> don't think it's a great tool. It has horrible bugs where
> cross-compiling is concerned (by which point it's not your project that
> has those bugs, which makes it all the more difficult to solve). It does
> take some headache away from you, and so I do use it occasionally, but I
> am not a great fan. If there was an easy way to generate shared
> libraries with automake without libtool, I would.
> 

libtool also tend to make the builds take much longer than needed out of being 
a thousands lines shell script. 

> Then again, about the competition:
> CMake - as far as I could dig up, it is even more restrictive than
> automake, require CMake itself to be ported and installed on the
> compiling platform, 

You can easily bootstrap CMake using its portable compilation step that is 
included in the source distribution and deploy it there.

> and its greatest touted advantage, that it is much
> simpler to learn than auto*, is irrelevant to me as I already know auto*.
> 

I never heard people touting the fact that CMake is simpler to learn than GNU 
Autotools (which is true, in my opinion) as an advantage. I've given bigger 
advantages to using CMake over GNU Autotools here:

http://www.shlomifish.org/open-source/anti/autohell/

Furthermore, while you already know Autotools, remember that you need to keep 
this knowledge resident in your memory, and that other people who wish to 
contribute to your projects will have to learn GNU Autotools up to the same 
level that your configuration files were written in (and to be able to handle 
other problems that crop).

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Rethinking CPAN - http://shlom.in/rethinking-cpan

Chuck Norris can make the statement "This statement is false" a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .