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.
The autotools suite requires that software developers keep revising things that worked before, because autotools has some new paradigm for some aspect of its operation every year or so.
For example, one of my open source projects lets the user specify which extra modules should be compiled into the binary. (It doesn't use loadable modules because that was even more painful when we started out.) Over a span of about two years -- and I think three "minor" (1.x) releases of automake -- the approved way of con
Over a span of about two years -- and I think three "minor" (1.x) releases of automake -- the approved way of conditionally linking object files changed twice.
You mean like this stopped working: if ENABLE_FOO mytarget_LDADD += libbar.a endif
if ENABLE_BAR mytarget_LDADD += libbar.a endif
I assumed you would build plugins into convenience libraries first, because it's an expected way to lay things out with automake; it also allows easy conversion to libtool usage, should you decide you need it (e.g. if you want those modules to be loadable after all).
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:5, Interesting)
The autotools suite requires that software developers keep revising things that worked before, because autotools has some new paradigm for some aspect of its operation every year or so.
For example, one of my open source projects lets the user specify which extra modules should be compiled into the binary. (It doesn't use loadable modules because that was even more painful when we started out.) Over a span of about two years -- and I think three "minor" (1.x) releases of automake -- the approved way of con
Re:I suppose it's nice (Score:1)
Over a span of about two years -- and I think three "minor" (1.x) releases of automake -- the approved way of conditionally linking object files changed twice.
You mean like this stopped working:
if ENABLE_FOO
mytarget_LDADD += libbar.a
endif
if ENABLE_BAR
mytarget_LDADD += libbar.a
endif
I assumed you would build plugins into convenience libraries first, because it's an expected way to lay things out with automake; it also allows easy conversion to libtool usage, should you decide you need it (e.g. if you want those modules to be loadable after all).