Cmake among others has effectively replaced autotools. It's FAR easier to deal with, cross platform, fast, will build makefiles, visual studio solutions, and X-code, and supports testing and other things.
There are some other ones around too like Scons, but the point is, anyone starting a new project now with autotools is a dolt or a masochist or both.
Autotools is dead. Let's let it be buried in peace, please.
I've just recently been in the situation of selecting a build system for a project with an existing codebase. I looked at the obvious alternatives, including cmake.
In the end, I chose autotools.
When you're doing a non-trivial project, cmake doesn't become any less complicated than autoconf and automake anymore - if your build is complex, you have to deal with that complexity somewhere after all. And there's a lot more and better resources for using autotools than cmake around, for figuring out odd corner cases. If you have a somewhat odd build requirement, chances are somebody else has already solved it using autotools already.
From my experience so far, most of what people dislike about using autotools come from Automake. But Automake is of course completely optional to use, and Autoconf - which provides most of the benefits - was made to be standalone. If you have a system with existing makefiles, it makes a lot of sense to simply use Autoconf to configure the app and the makefiles and leave Automake alone.
From my experience so far, most of what people dislike about using autotools come from Automake. But Automake is of course completely optional to use, and Autoconf - which provides most of the benefits - was made to be standalone. If you have a system with existing makefiles, it makes a lot of sense to simply use Autoconf to configure the app and the makefiles and leave Automake alone.
That's until you go into building shared libraries for multiple platforms. Then automake and libtool are your saviors. Also, I find automated header dependency tracking nice to use.
I agree -- autoconf is independent, and does a great job handling system configuration stuff without involving automake -- but I think you're being a bit unfair to automake.
For projects that "fit" automake, it's actually a wonderful tool, as it allows a highly concise description of the package contents and dependencies, with almost zero fat and overhead, and does pretty much all the typical boilerplate stuff (convenience targets, separate build-directory support, installation, automatic dependency generat
"For projects that "fit" automake, it's actually a wonderful tool,..."
You're absolutely right, and it seems to save a huge amount of headaches when you can use it. Note though that I'm adapting an existing codebase, that needs a certain structure to be buildable using non-unix tools and systems. While I can get a more or less buildable version using Automake there's enough oddities to deal with that adapting the previous hand-rolled makefile seems preferable.
The confusion of a staff member is measured by the length of his memos.
-- New York Times, Jan. 20, 1981
Autotools do not need a book (Score:5, Insightful)
... they should be replaced by something else.
Re: (Score:1, Interesting)
They have been.
Cmake among others has effectively replaced autotools. It's FAR easier to deal with, cross platform, fast, will build makefiles, visual studio solutions, and X-code, and supports testing and other things.
There are some other ones around too like Scons, but the point is, anyone starting a new project now with autotools is a dolt or a masochist or both.
Autotools is dead. Let's let it be buried in peace, please.
Re:Autotools do not need a book (Score:5, Interesting)
I've just recently been in the situation of selecting a build system for a project with an existing codebase. I looked at the obvious alternatives, including cmake.
In the end, I chose autotools.
When you're doing a non-trivial project, cmake doesn't become any less complicated than autoconf and automake anymore - if your build is complex, you have to deal with that complexity somewhere after all. And there's a lot more and better resources for using autotools than cmake around, for figuring out odd corner cases. If you have a somewhat odd build requirement, chances are somebody else has already solved it using autotools already.
From my experience so far, most of what people dislike about using autotools come from Automake. But Automake is of course completely optional to use, and Autoconf - which provides most of the benefits - was made to be standalone. If you have a system with existing makefiles, it makes a lot of sense to simply use Autoconf to configure the app and the makefiles and leave Automake alone.
This is a lengthy but really illuminating document on using the autotools, that specifically goes through using autoconf alone and on how to adapt an existing project: http://www.freesoftwaremagazine.com/books/agaal/brief_introduction_to_gnu_autotools/ [freesoftwaremagazine.com]
Re: (Score:1)
"In case you didn't notice, the article you linked to was written by the same guy who wrote the book being reviewed, John Calcote."
Ah, you're right. Time to buy that book, then.
Re: (Score:1)
From my experience so far, most of what people dislike about using autotools come from Automake. But Automake is of course completely optional to use, and Autoconf - which provides most of the benefits - was made to be standalone. If you have a system with existing makefiles, it makes a lot of sense to simply use Autoconf to configure the app and the makefiles and leave Automake alone.
That's until you go into building shared libraries for multiple platforms. Then automake and libtool are your saviors. Also, I find automated header dependency tracking nice to use.
Re: (Score:3, Interesting)
I agree -- autoconf is independent, and does a great job handling system configuration stuff without involving automake -- but I think you're being a bit unfair to automake.
For projects that "fit" automake, it's actually a wonderful tool, as it allows a highly concise description of the package contents and dependencies, with almost zero fat and overhead, and does pretty much all the typical boilerplate stuff (convenience targets, separate build-directory support, installation, automatic dependency generat
Re: (Score:1)
"For projects that "fit" automake, it's actually a wonderful tool, ..."
You're absolutely right, and it seems to save a huge amount of headaches when you can use it. Note though that I'm adapting an existing codebase, that needs a certain structure to be buildable using non-unix tools and systems. While I can get a more or less buildable version using Automake there's enough oddities to deal with that adapting the previous hand-rolled makefile seems preferable.