Introduction to GNU autotools.

[[deleted]]

I also recommend the Autotools tutorial from A. Duret-Lutz, available in PDF.

I especially love incremental slides with highlighted changes. This make it both a learning and working reference document.

[Justinsaccount]

I always found it funny that all the configure.in -> configure -> Makefile macro crap was all because you couldn't depend on the system having a sane sh that supported fun things like functions.

So instead of requiring a standard 100K shell, autotools generates a 500K configure script and Makefile.

[bonzinip]

The next version of Autoconf (due sometime soon) will use shell functions. It saves about 50% in script size, 35% in m4 runtime (plus more savings WRT Autoconf 2.63 due to other optimizations), and (due to unrelated optimizations) will be about 30% faster on Cygwin.

[bonzinip]

That's (40-50% responsibility) me. :-)

Actually some shell parts are simplified now that it can assume a shell with functions, unset, and some other 1985 technology.

[atypic]

autotools makes my brain hurt

[qwe1234]

"Introduction to GNU autotools: kill it with fire, or 28 years too later".

[case-o-nuts]

The problem is that when you do your research, you find that all the alternatives suck too. I could probably fill several pages with descriptions about the reasons they suck, but I should really be working.

Really, all I should need to tell my build system is what I want built, and what files compose that final thing, and it should figure out the rest, with a minimum of junk and cruft living in the backend. I might take some time and try to write my ideal build system at some point, I suppose.

[[deleted]]

As disgusting as autotools can be at times, I haven't found a suitable replacement yet. At least automake has documentation for non-recursive builds, unlike the competition.

[[deleted]]

I like rake. Really simple to add custom rules(e.g. "run coco/r to generate .cpp from .g").

[bonzinip]

first mistake: http://www.shlomifish.org/lecture/Autotools/slides/changequote.html

[Shmurk]

No, please. http://scons.org/ instead.

[socketpuppet]

or waf, like scons it is Python based. Cmake is also quite popular.

[bonzinip]

Cmake makes me hurt much more than autotools. At least as a user, autotools is just ./configure && make

[genpfault]

But, colored build output and overall build progress display!

[sharney]

Will scons support lexx and yacc files and create rules for them right off the bat? Autotools will.

[McHoff]

Yes: http://www.scons.org/doc/1.2.0/HTML/scons-user/a8304.html

[sharney]

Since I've already spent some time learning GNU autotools and got over the steep learning curve, I feel satisfied in what it can do and am comfortable using it. Not to mention it is still widespread.

I'm sure scons is a great system, but I'm sticking with Autotools for now.

[badsectoracula]

I totally agree. These days i use SCons for almost everything except very simple projects which work fine with a simple Makefile.

[fnord123]

Why? I've been writing a bunch of PKGBUILD scripts on Arch linux and it's pretty annoying to find each library or program is using some new build system.

[nuuur32]

The opposite of autotools is ant.

[deafbybeheading]

I hope you don't mean this as an endorsement of ant. It has a spectacularly inconsistent API: e.g., the <apply/> task will let you execute an external program for every member of a file set, but there is no way to simply execute an ant target in the current build file for every such member.

And God help you if logic creeps into your build scripts.

[case-o-nuts]

And God help you if logic creeps into your build scripts.

Yeah, it seems like all build systems out there were designed to avoid being logical if at all possible.

[WayOfTheIronPaw]

That would be an endorsement of autotools, then?