Why use build tools like Autotools when we can just write our own makefiles?

You are talking about two separate, but intertwined things here.

You are talking about two separate, but intertwined things here: Autotools GNU coding standards Within Autotools, you have several projects: Autoconf Automake Libtool Let's look at each one individually. Autoconf Autoconf easily scans an existing tree to find its dependencies and create a configure script that will run under almost any kind of shell. The configure script allows the user to control the build behavior (i.e.

--with-foo, --without-foo, --prefix, --sysconfdir, etc..), as well as does checks to ensure that the system can compile the program. Configure generates a config. H file (from a template) which programs can include to work around portability issues.

For example, if HAVE_LIBPTHREAD is not defined, use forks instead. I personally use Autoconf on many projects. It usually takes people some time to get used to m4, however it does save time.

You can have makefiles inherit some of the values that configure finds without using automake. Automake By providing a short template that describes what programs will be built and what objects need to be linked to build them, Makefiles that adhere to GNU coding standards can automatically be created. This includes dependency handling and all of the required GNU targets.

Some people find this easier, I prefer to write my own makefiles. Libtool Libtool is a very cool tool for simplifying the building and installation of shared libraries on any Unix-like system. Sometimes I use it, other times (especially when just building static link objects) I do it by hand.

There are other options too, see Stack Overflow question Alternatives to Autoconf and Autotools?. In short, you really should use some kind of portable build configuration system if you release your code to the masses. What you use is up to you.

GNU software is known to build and run on almost anything, however you might not need to adhere to such (and sometimes extremely pedantic) standards. If anything, I'd recommend giving Autoconf a try if you're writing software for POSIX systems. If you need documentation and how-to links, update your question.

Edit Don't fear m4 :) There is always the Autoconf macro archive. Plenty of examples, or drop in checks .. write your own or use what's tested. Autoconf is far too often confused with Automake, they are two separate things.

1 +1: well reasoned and very detailled – David Schmitt Apr 5 '09 at 15:19 1 +1, though libtools is the spawn of the devil. Personally, I'm starting to use cmake for some of my projects, but it's hard to beat the flexibility of autotools. – janneb Apr 5 '09 at 15:37 @janneb: Yes, but with flexibility comes complexity.

I just wish there was an easier starting point for the newbie. – Loki Astari Apr 5 '09 at 15:48 1 +1, nice clear summary. I've been too scared to use autotools thus far but that may change in time.

– j_random_hacker Apr 6 '09 at 3:31 @j_random_hacker, don't fear m4 .. once you get used to it, its far easier than writing your own scripts. Yeah, I know, stuff that looks like LISP makes people shudder, but its not LISP. To help you, here are your father's parenthesis: (((((((((((((((((())))))))))))))))) – Tim Post?

Apr 6 '09 at 10:17.

First of all, the Autotools are not an opaque build system but a loosely coupled tool-chain, as tinkertim already pointed out. Let me just add some thoughts on Autoconf and Automake: Autoconf is the configuration system that creates the configure script based on feature checks that are supposed to work on all kinds of platforms. A lot of system knowledge has gone into its m4 macro database during the 15 years of its existence.

On the one hand, I think the latter is the main reason Autotools have not been replaced by something else yet. On the other hand, Autoconf used to be far more important when the target platforms were more heterogeneous and Linux, AIX, HP-UX, SunOS, ..., and a large variety of different processor architecture had to be supported. I don't really see its point if you only want to support recent Linux distributions and Intel-compatible processors.

Automake is an abstraction layer for GNU Make and acts as a Makefile generator from simpler templates. A number of projects eventually got rid of the Automake abstraction and reverted to writing Makefiles manually because you lose control over your Makefiles and you might not need all the canned build targets that obfuscate your Makefile. Now to the alternatives (and I strongly suggest an alternative to Autotools based on your requirements): CMake's most notable achievement is replacing AutoTools in KDE.It's probably the closest you can get if you want to have Autoconf-like functionality without m4 idiosyncrasies.

It brings Windows support to the table and has proven to be applicable in large projects. My beef with CMake is that it is still a Makefile-generator (at least on Linux) with all its immanent problems (e.g. Makefile debugging, timestamp signatures, implicit dependency order). SCons is a Make replacement written in Python.

It uses Python scripts as build control files allowing very sophisticated techniques. Unfortunately, its configuration system is not on par with Autoconf. SCons is often used for in-house development when adaptation to specific requirements is more important than following conventions.

If you really want to stick with Autotools, I strongly suggest to read Recursive Make Considered Harmful and write your own GNU Makefile configured through Autoconf.

Autoconf has many more uses than just trivial checks, for instance, quickly find out if struct foo in foo/foo. H has a member named 'bar', the version of libfoo, etc. Plus, the build time options really help when making . Deb / .

Rpm packages. But, yeah, its a matter of preference I suppose. – Tim Post?

Apr 6 '09 at 2:22 +1 for useful info. I'd give you another +1 for mentioning "Recursive Make Considered Harmful" if I could -- this has to be one of the most underappreciated documents in IT. – j_random_hacker Apr 6 '09 at 3:34 @tinkertim: You're right, but that doesn't set Autoconf apart in contrast to other build systems.

The examples you've given can be easily implemented in SConf (SCons' configuration sub-system). However, all the sanity checks and things I would not even think of checking come for free in Autoconf. – Pankrat Apr 6 '09 at 11:08.

Autotools are needed because Makefiles are not guaranteed to work the same across different platforms. If you handwrite a Makefile, and it works on your machine, there is a good chance that it won't on mine.

For small projects or even for large projects that only run on one platform, handwritten makefiles are the way to go. Where autotools really shine is when you are compiling for different platforms that require different options. Autotools is frequently the brains behind the typical .

/configure make make install compilation and install steps for Linux libraries and applications. That said, I find autotools to be a pain and I've been looking for a better system. Lately I've been using bjam, but that also has its drawbacks.

Good luck finding what works for you.

The *nix world is a cross-platform landscape, and your build and install tools need to deal with that. Mind you, the auto* tools date from an earlier epoch, and there are many valid complaints about them, but the several projects to replace them with more modern alternatives are having trouble developing a lot of momentum. Lots of things are like that in the *nix world.

The answers already provided here are good, but I'd strongly recommend not taking the advice to write your own makefile if you have anything resembling a standard C/C++ project. We need the autotools instead of handwritten makefiles because a standard-compliant makefile generated by automake offers a lot of useful targets under well-known names, and providing all these targets by hand is tedious and error-prone. Firstly, writing a Makefile by hand seems a great idea at first, but most people will not bother to write more than the rules for all, install and maybe clean.

Automake generates dist, distcheck, clean, distclean, uninstall and all these little helpers. These additional targets are a great boon to the sysadmin that will eventually install your software. Secondly, providing all these targets in a portable and flexible way is quite error-prone.

I've done a lot of cross-compilation to Windows targets recently, and the autotools performed just great. In contrast to most hand-written files, which were mostly a pain in the ass to compile. Mind you, it is possible to create a good Makefile by hand.

But don't overestimate yourself, it takes a lot of experience and knowledge about a bunch of different systems, and automake creates great Makefiles for you right out of the box. Edit: And don't be tempted to use the "alternatives". CMake and friends are a horror to the deployer because they aren't interface-compatible to configure and friends.

Every half-way competent sysadmin or developer can do great things like cross-compilation or simple things like setting a prefix out of his head or with a simple --help with a configure script. But you are damned to spend an hour or three when you have to do such things with BJam. Don't get me wrong, BJam is probably a great system under the hood, but it's a pain in the ass to use because there are almost no projects using it and very little and incomplete documentation.

Autoconf and automake have a huge lead here in terms of established knowledge. So, even though I'm a bit late with this advice for this question: Do yourself a favor and use the autotools and automake. The syntax might be a bit strange, but they do a way better job than 99% of the developers do on their own.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.