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

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?

  • there is nothing like just 'code'. For example if you get Java code you probably will build it using maven or ant, if you get Python a good choice is setuptools. There are not standard ways to compile anything. Maybe you should reformulate the question.
    – diega
    Aug 10, 2010 at 23:25
  • Good point. I'm actually coding in C# with mono, but my question applies to C/C++ as well. Aug 10, 2010 at 23:35
  • Small note: autogen.sh does not execute make for you, just configure.
    – Sandy
    Aug 11, 2010 at 13:21
  • @Sandy autogen.sh are mostly custom scripts, that usually invoke autoreconf but also might invoke ./configure and even make. I don't think that its behaviour is standardized in any way; the main purpose is in having an exetable file within the project, which people can run (rather than having to know that they need to conjure autoreconf)
    – umläute
    Oct 19, 2016 at 9:28

5 Answers 5


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:

Set things up in the BSD way
Set things up in the SystemV way

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:

Use Send here
Use something else

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

  • Just a minor nit: The GNU standards mandate shipping generated files in tarballs, to reduce the build dependencies to a minimum of universally available tools. If you get raw source (from a version control system, for instance), the generated files won't be there.
    – vonbrand
    Mar 15, 2013 at 16:40

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.


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.

  • 2
    Portability is not the problem since Python is now virtually everywhere. The main complaint about SCons so far is that it is unacceptably slow. There are some tweaks to sacrifice build accuracy in favour of speed, but I'm not sure if it's still on par with Make.
    – Alex B
    Aug 10, 2010 at 23:43

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. ;-)

  • Yeah, I know about xbuild, but I'm trying to wean myself from IDEs that just want to hold my hand. Plus, Mono is compiled using Mono and uses autoconf, so I wanted to know a bit more. Thanks! Aug 11, 2010 at 14:26
  • 1
    Interestingly, lots of Mono projects are trying to migrate to msbuild now that xbuild is working so well. It makes Windows/Mac support a bit easier. Mono has so much C code that I'm not sure how practical it would be for them to move to xbuild. But autoconf works great, so do whatever works for you. :-)
    – Sandy
    Aug 11, 2010 at 17:31

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .