
Introduction to the Autotools (2012) - ingve
http://www.dwheeler.com/autotools/
======
adekok
I've used autotools for >15 years now. My $0.02 is the following:

\- autoconf is horrible but useful. It's bloated, slow, obtuse, and hard to
use. But it encapsulates a portability layer which was useful 15 years ago...
and less so today

\- automake is horrible. A few simple rules in GNU Makefile syntax are good
enough for the majority of projects. And it's easier to understand than
automake

\- libtool is horrible. It slows down every build by a factor of ~10. And
you'd think that a program _dedicated to building C programs_ would be written
in C. You know, for speed. But no... it's written in shell. Horrible,
horrible, shell. And it _breaks_ the build. Pass "-L/foo -lbar"? It randomly
converts it to an absolute path "/foo/bar.so". Pass in an absolute path so
that you can link against the LOCAL build directory for testing? Screw you...
it re-writes that to a relative path, and links against the system libraries.

\- libltdl should be shot. I got rid of it in my projects 5 years ago, and
never looked back. Everything sane has dlopen() these days.

If you want a nice cross-platform replacement for these tools, look at what
nginx has done. ~8K lines of code, largely Makefiles split into ~50 lines.
Simple, clean, and well organized.

------
Frondo
I'd like to jump in and endorse CMake, too, after spending some frustrated
nights some years ago trying to add autogoo to a project.

It was so mindblowingly easy to get CMake to work--to detect/find paths for
libraries, work on Linux and Windows, the whole nine yards--on a project I
had, I had the basic cross-platform functionality up in a matter of hours on
my very first attempt.

And the makefiles it produces generate pretty colored output. :-)

Autogoo knowledge seems like it's about on par with a deep knowledge of Xlib--
good for anyone maintaining a legacy project, I'm sure.

~~~
jordigh
> Linux and Windows, the whole nine yards

That's the thing, if (a specific distribution of) Linux and Windows are all
you care about, then CMake does the job just fine. Autotools solves the
problem of being portable to every conceivable Unix, including many Unices
people don't use anymore, and including Unixified Windows.

Also, autotools solves the problem in a very specific way, _test for features,
not for versions_ :

[https://news.ycombinator.com/item?id=10752054](https://news.ycombinator.com/item?id=10752054)

~~~
Frondo
That sounds like what I said--portability to every conceivable unix, including
ones that people no longer use--that autotools is good for legacy support.

I'm trying to see what benefit there it to start a project in 2016 and wrestle
with autotools, just so that you also gain access to unixes no one uses.

~~~
therein
Yeah, exactly. I don't think my C++11 code would be portable to ultirx and
dg/ux anyway. :)

------
derFunk
Not coming from active c/cpp development, but learned it at University, I had
to deal with autotools just last week. I have to admit I was facing a steep
learning curve. All I wanted to do is adjusting some build parameters of an
existing OS project (like adding compiler flags etc), which has several sub
projects and is also calling non cpp-compilers (mono). Normally I'm an
extremely fast learner, but this gave me something to chew on a few hours. I
was frustrated and gave up when I accomplished 85% of what I originally wanted
to achieve (because time didn't permit to spend more on this). I don't mean to
say these tools are hard to comprehend/master in general, but for folks like
me coming from other software ecosystems it seems it's a tough bit. At least
it was for me :)

~~~
dmm
Setting compiler flags with autoconf should be simple:

    
    
         ./configure CC=gcc44 CXX=g++44 CFLAGS="-m32" CXXFLAGS="-m32"
    

If that doesn't work something is wrong with the implementation.

------
michaelmior
Autotools Mythbuster[0] is another great resource.

[0] [https://autotools.io/index.html](https://autotools.io/index.html)

~~~
JadeNB
I get a 403 Forbidden.

~~~
kwhitefoot
Works for me.

~~~
joneholland
Myth busted.

------
antonyme
This documentation and video is good if you want to use autotools. But in
2016, you should really be asking yourself if autotools is the right choice.
It is rather baroque, and there are many other choices these days that provide
similar functionality for less developer time and effort.

~~~
highwind
Could you provide some examples of other choices that you speak of? Thank you.

~~~
thallian
waf ([https://waf.io/](https://waf.io/))

~~~
JoshTriplett
Please don't use waf. It does not provide a stable API from version to
version, and encourages projects to embed a binary compiled version of waf.
Unlike autotools, where you can ship configure.ac and Makefile.am and expect
developers to run autoreconf after obtaining the project from version control,
you can't easily do the same thing with waf due to the lack of versioning.

~~~
ziotom78
"Binary compiled"? Isn't waf a Python script?

~~~
JoshTriplett
See the compiled version linked from the waf homepage, which projects using
waf include in their source tree. That compiled version consists of a small
Python stub followed by bz2-compressed data and a signature.

------
joepvd
This is awesome. Have just been strugglingh to get started with this the past
few evenings. Will take this as my guide. Thanks for posting!

BTW, good place to start learning the relevant parts of GCC?

~~~
rhodysurf
If youre just starting something and not maintaining something older you
should really take a look into CMake

~~~
wootoomoo
I'm pretty baffled that people recommend CMake so often. I looked into it, and
found:

* The worst scripting language ever, seemingly made by someone without even basic theoretical knowledge of language parsing. It's even worse than shell scripting.

* The same I-don't-care copypasta culture most autotools users seem to follow, but the free documentation was even worse (or at least back when I tried it). There's a book which I didn't have access to, though.

* Less enduser/packager friendly, with worse help texts, documentation, and features (seems to have caught up somewhat). Plus, everybody already knows how configure scripts work.

* The portability to Windows in reality means lots of if(WIN32) branches.

* The results are often brittle. This is also true of autotools in practice, but at least there is some info out there about how to write autoconf macros correctly. Even the .cmake files that ship with CMake seemed to be thrown together carelessly the last time I looked.

* Also, CMakeLists.txt must be the worst filename for a script I've ever seen. I'm only half serious on that one. I know it doesn't matter, but it bothers me terribly. It's ugly and misleading and makes me question the author's sense of aesthetics and basic competence.

CMake is terrible. Autotools is also terrible, but at least it's got an
excuse. Just learn your damn tools. The real problem with autoconf is that
nobody wants to invest any time learning about their build system and instead
just copy-pastes it around, creating a brittle mess. From the CMake projects
I've seen, it doesn't really solve this problem at all, creating a similar
mess. And now your users have to install CMake and figure out how it works,
and it doesn't even print a useful --help text.

~~~
joepvd
Appreciate your opinion. Have been looking into CMake this evening, and my
little impression was that it does not make the problem smaller, just
different. The things I have been searching for, also did not yield that much
high quality answers. Think I will stick to learn autotools enough, as that
might come in more handy in general.

------
ised
Whenever this gets posted, comments seem to focus on what to use going
forward. It seems obvious for most projects there are better alternatives.

However whenever I see autotools documentation I think of only one thing: it's
worth learning how this old system works because, even if you will never
yourself use it for your own projects, so much code written by others over
past decades requires autoconf, automake, often libtool, and sometimes pkg-
config.

For me, understanding how these old hacks work is very important in getting a
large majority of open source software projects to compile after I make
modifications, e.g., removing code.

Oftentimes I think that people who use autotools do not truly understand _how
it works_, they have only figured out _how to use it_. This is reasonable but
the problem is that autotools is very brittle, and if it breaks they have
little idea how to fix it.

------
_RPM
An advantage of using Autotools is that a lot of awesome software for Unix
like systems use it as there build process.

------
aurora72
CMake is just another automatic build tool like the Autotools but without the
Bourne shell requirement and the one which easily produces XCode / Visual
Studio project files like the QMake. So as far as the CMake is concerned, it's
not particularly useful nor more time saving than Autotools really.

