[yorhel]

Please do use autotools! You only need two files: configure.ac and Makefile.am, both at the top-level of your project. The autogenerated stuff can be ignored, you don't have to learn M4 to use autoconf. And (if you are a bit careful, but that's not too hard) you'll have many nice features such as out-of-source builds, proper feature checking, amazing portability, 'make distcheck', and acceptable cross-compiling (still hard to get right, but the alternatives tend to be even harder). Don't switch to another build system purely based on the idea that it's "more elegant".

[ambrop7]

  $ tar xf autotools-using-package.tar.bz2
  $ cd autotools-using-package

Configure, compile, install. Oh, I found this little bug. Let's try to fix it ... edits configure.ac ....

  $ ./autogen.sh
  Error: possibly undefined macro AC_BLABLABA

Spend some hours figuring this out... Oh, I need to install an old version of auto*! How do I get the old one but keep the new one around? Spend another 30 minutes to figure that out.

  $ ./autogen.sh
  checking for build system type...
  ^C

No damn, I wanted to generate configure, not run it! How do I clean up the mess it made just now?

  $ make clean
  $ make distclean
  $ ./configure --prefix=$HOME/my_app ...
  $ make -j9 install
  ...
  install: no such file or directory blabla.la

WTF!?!?! Spend an hour or so googling this mess. Ah, it's a parallel-make bug.

  $ make install

HOLY SHIT, IT INSTALLED!!!

Let's submit this fix upstream. No problem, use diff.

  $ mkdir temp
  $ tar xf autotools-using-package.tar.bz2 -C temp
  $ mv temp/autotools-using-package autotools-using-package.orig
  $ diff -urN autotools-using-package.orig autotools-using-package

WTF IS ALL THIS MESS IN THE DIFF I NEVER TOUCHED?!!??!

I know you're going to say I should be using the VCS checkout in the first place, which would hopefully be configured to ignore the autogenerated files. But as a user, or distribution maintainer, most of the time the bug you find is with a specific, packaged version of the software, and it may be quite an effort to figure out how to get the exact same version from the VCS server.

[JoshTriplett]

> $ ./autogen.sh > checking for build system type... > ^C > > No damn, I wanted to generate configure, not run it! How do I clean up the mess it made just now?

I always run "./autogen.sh --help" for exactly that reason; then if I see --help output from configure, I know that autogen.sh "helpfully" ran configure for me.

You can also usually just run "autoreconf -v -f -i" directly, unless the package has done something unusual that it needs to take extra steps in autogen for.

[J_Darnley]

This just about sums up my experience with autotools except for the fact that I quit in frustration after step 2.

[bjourne]

Practically, you need an autogen.sh script too because noone knows the command switches and order you need to call aclocal, autoconf and automake in to generate the configure script and Makefile.in files. That's enough for a minimal project. For something larger with subdirectories for src/ docs/ tests/ etc, you need to use one Makefile.am file in each directory and tie it together with the SUBDIRS variable. When you need to do something slightly out of the extra-ordinary (in autotools' world, "ordinary" means compile c, generate man pages and install) like generating doxygen or javadoc documentation, offering an uninstall option or building binaries that are not supposed to be installed, then you have to learn M4 and it's stupid syntax.

Also, autotools amazing features aren't all that. Builds out of the source dir? Eh.. This is 2012 and it doesn't impress anymore. Both waf and SCons can do it no problem. Autotools-projects, on the other hand, seem to always put the object files and linked library in the source directory. Sometimes the built library is put in a hidden directory for some reason I don't understand. Possibly it has something to do with libtool, another kludge on top of autotools one rather would do without. Since modern build tools does not pollute the source directories you basically get make distcheck for free. Waf has it builtin for example and it can easily be extended to also upload your tarballs to your distribution server, sending annoncement emails and what have you.

[i386]

If anyone could tell me a way todo what you describe without copying and checking in 'mystery meat' autofoo and m4 files into my project, I would.

[AngryParsley]

I don't want to toot my own horn, but I only check in Makefile.am and configure.ac. Here's a simple example I made a while back: https://github.com/ggreer/fsevents-tools. To build it, just run autogen.sh.

For a "real" project, https://github.com/ggreer/the_silver_searcher, I have the same set-up: Makefile.am and configure.ac with no generated code in the repo. It works fine as long as you have pkg-config, and most people do. It builds and runs on Solaris, OS X, FreeBSD, and any Linux distro you like.

Although I use autotools the "right way", I'm not a fan of it at all. There are multiple levels of generated files. Configure is generated from configure.in which is generated from configure.ac. Makefile is generated from configure and Makefile.in. Makefile.in is generated from Makefile.am. There are other files in the mix as well. Config.h, config.h.in, aclocal.m4, and various symlinks to autotools (compile, depcomp, install-sh, and missing) get generated. It's insane.

There are other problems. Minor versions of autotools can behave completely differently. AM_SILENT_MAKE was removed between automake 1.10 and 1.11. Instead of printing out minimal text during a build, scripts using that macro crash. Another example: 1.9 requires AM_PROG_CC_C_O to compile anything useful but 1.10 doesn't. What's crazy is that 1.9 actually spits out an error message telling you to add AM_PROG_CC_C_O to your configure.ac. It makes no sense.

A system this complicated can't be pruned without breaking backwards compatibility. For autotools, that's not feasible. There are too many projects that would need to be fixed. The next-best solution is to use something else for new projects and let autotools fade gently into history.

[yorhel]

Start with the Autotools Mythbuster: http://www.flameeyes.eu/autotools-mythbuster/ The autoconf & automake documentation is generally quite good as well.