I suppose it's nice that someone writes a book like this, since a lot of existing projects use autotools (or more commonly, try to by means of copy/paste and cargo-cult based build scripting).
But autotools should really be phased out. It solves a lot of problems that aren't problems anymore, and makes a helluva lot of new ones in the process. There are a lot of up and coming build systems to challenge it, and then there's CMake which is an OK compromise between those and practicality.
Care to point out what new problems autotools creates? From my experience, autotools projects tend to work flawlessly while cmake ones tend to throw a lot of obscure errors that no one is able to figure out.
> Care to point out what new problems autotools creates?
Builds that take half an hour just to "configure", checking for the existence of things like strcpy(), but anyway fail at compile or link time because a missing symbol in an upgraded dynamic library?
Either your build machine is too slow/overloaded, or the source tree is unusably large and complex anyway, so it needs splitting to smaller, saner projects. What can a non-nested configure script even do for more than five minutes? You can also look for unnecessary checks in configure.ac; IIRC recent autoconfs check some smallish list of libc functions by default. I don't know why do even that, but it never held me back for any significant time to have these checks running. Look at any "utility" macros usually copied ad-hoc from some other project and left to rot. These tend to be sloppily written, use macros from obsolete versions of autoconf or automake, and do some misguided things; it's these macros that give autoconf a bad name.
Ok, I exaggerated with the time... but only assuming that your build will be successful on the first execution (in my experience this is rarely the case.) So you end re-executing configure (with other options or after altering the system in some way). That way it's not uncommon to dedicate several hours for the build, with a lot of that time consumed in the configure executions.
Children begin by loving their parents. After a time they judge them. Rarely,
if ever, do they forgive them.
- Oscar Wilde
I suppose it's nice (Score:5, Insightful)
I suppose it's nice that someone writes a book like this, since a lot of existing projects use autotools (or more commonly, try to by means of copy/paste and cargo-cult based build scripting).
But autotools should really be phased out. It solves a lot of problems that aren't problems anymore, and makes a helluva lot of new ones in the process. There are a lot of up and coming build systems to challenge it, and then there's CMake which is an OK compromise between those and practicality.
Re: (Score:1, Interesting)
Care to point out what new problems autotools creates? From my experience, autotools projects tend to work flawlessly while cmake ones tend to throw a lot of obscure errors that no one is able to figure out.
Re: (Score:4, Insightful)
> Care to point out what new problems autotools creates?
Builds that take half an hour just to "configure", checking for the existence of things like strcpy(), but anyway fail at compile or link time because a missing symbol in an upgraded dynamic library?
Re:I suppose it's nice (Score:1)
Builds that take half an hour just to "configure"
Either your build machine is too slow/overloaded, or the source tree is unusably large and complex anyway, so it needs splitting to smaller, saner projects. What can a non-nested configure script even do for more than five minutes?
You can also look for unnecessary checks in configure.ac; IIRC recent autoconfs check some smallish list of libc functions by default. I don't know why do even that, but it never held me back for any significant time to have these checks running.
Look at any "utility" macros usually copied ad-hoc from some other project and left to rot. These tend to be sloppily written, use macros from obsolete versions of autoconf or automake, and do some misguided things; it's these macros that give autoconf a bad name.
Re: (Score:2)
Ok, I exaggerated with the time... but only assuming that your build will be successful on the first execution (in my experience this is rarely the case.) So you end re-executing configure (with other options or after altering the system in some way). That way it's not uncommon to dedicate several hours for the build, with a lot of that time consumed in the configure executions.