Is automake and autoconf the standard way to compile code?

Question

I sometimes compile apps from source and I've either been using:

./configure
make
sudo make install

But recently, I came across ./autogen.sh which generates the configure and make scripts for me and executes them.

What other methods to streamline C/C++/C#(mono) compilation exist? Make seems a bit old. Are there new tools out there? Given the choice, which one should I use?

Answer 1

Autoconf and Automake were set out to solve an evolutionary problem of Unix.

As Unix evolved into different directions, developers that wanted portable code tended to write code like this:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

As Unix was forked into different implementations (BSD, SystemV, many vendor forks, and later Linux and other Unix-like systems) it became important for developers that wanted to write portable code to write code that depended not on a particular brand of operating system, but on features exposed by the operating system. This is important because a Unix version would introduce a new feature, for example the "send" system call, and later other operating systems would adopt it. Instead of having a spaghetti of code that checked for brands and versions, developers started probing by features, so code became:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

Most README files to compile source code back in the 90's pointed developers to edit a config.h file and comment out that proper features available on the system, or would ship standard config.h files for each operating system configuration that had been tested.

This process was both cumbersome and error prone and this is how Autoconf came to be. You should think of Autoconf as a language made up of shell commands with special macros that was able to replace the human editing process of the config.h with a tool that probed the operating system for the functionality.

You would typically write your probing code in the file configure.ac and then run the autoconf command which would compile this file to the executable configure command that you have seen used.

So when you run ./configure && make you were probing for the features available on your system and then building the executable with the configuration that was detected.

When open source projects started using source code control systems, it made sense to check in the configure.ac file, but not the result of the compilation (configure). The autogen.sh is merely a small script that invokes the autoconf compiler with the right command arguments for you.

--

Automake grew also out of existing practices in the community. The GNU project standardized a regular set of targets for Makefiles:

• make all would build the project
• make clean would remove all compiled files from the project
• make install would install the software
• things like make dist and make distcheck would prepare the source for distribution and verify that the result was a complete source code package
• and so on...

Building compliant makefiles became burdensome because there was a lot of boilerplate that was repeated over and over. So Automake was a new compiler that integrated with autoconf and processed "source" Makefile's (named Makefile.am) into Makefiles that could then be fed to Autoconf.

The automake/autoconf toolchain actually uses a number of other helper tools and they are augmented by other components for other specific tasks. As the complexity of running these commands in order grew, the need for a ready-to-run script was born, and this is where autogen.sh came from.

As far as I know of, Gnome was project that introduced the use of this helper script autogen.sh

Answer 2

There are two "Big players" in this area; Cmake, and GNU Autotools.

• GNU Autotools is the GNU way to do things, and is fairly focused on *nix. It's a sort of meta-build system, providing a set of tools that generate specific config and make files for what you're trying to do. This helps you make more changes in your code without having to directly manipulate your build system, and it helps others build your code in ways you hadn't designed for - under *nix.

• Cmake is the cross-platform way to do things. The Cmake team builds software on many many many different ways, with GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU/Linux, whatever. If you are at all concerned with portability of your code base, this is the way to go.

As has been mentioned, some people appear to be fond of Scons. If you're familiar with Python this might provide more consistency in your working environment.

Ruby also has a sort of meta-build system called Rake, which is pretty cool in it's own right, and is very handy for those already familiar with Ruby.

Answer 3

Scons is one possible replacement, though I have no personal experience. It's also implemented in Python, which could be a problem, depending on the build environment.

Answer 4

If you're using C#/Mono, you can use msbuild (the .sln/.csproj files used by MonoDevelop and Visual Studio) to manage your entire build process.

You can then either build from MonoDevelop, or run the xbuild command in your favorite terminal (works best in Mono >= 2.6). This is extremely easy and requires pretty much no work on your part, because MonoDevelop will handle the msbuild files for you, and you won't need to edit them unless you want to tweak things beyond what MonoDevelop's UI can do for you.

I'm not familiar with how people who depend on msbuild handle the installs for their projects, but you could always ask that. ;-)

Answer 5

For C# you can use xbuild (and msbuild on windows), which will build the project from your project files.