l'amphi-gouri

Ce qui suit est un condensé filtré de l'article sur freshmeat Stop the autoconf insanity! Why we need a new build system.. Si quelqu'un a envie de faire une synthèse des commentaires sur linuxfr à propos de l'article sur freshmeat, la section "commentaires" est pour lui...

Les outils sont classé par nombre d'occurences dans la discussion (à la louche). Scons semble s'en sortir bien.

Autotools

• I will not talk about automake here - I don't like it, I don't use it. (...) Autoconf, however, is a very good tool, and in my opinion, has good documentation. (...) There is also the Autobook, which I found very valuable when I was trying to graps the bigger picture. (...) Anyway, that's just my opinion. I use autoconf because it Just Works, and was easy to learn, unlike some of the other alternatives suggested in this thread.

• La documentation : Autobook

• a good tutorial or information about making a Makefile and configure script using auto* tools It is a great tutorial and will teach you all you need to know to understand how great a system these auto* tools really are. Don't be scared by the length either, the first section really gives you all you need to know for a simple program and then you can skim and add the pieces you need. It's not hard so read before posting,

• In short autoconf rules, automake sucks, and I'm happy to see that this opinion is shared by at least 1 other person in the world.

SCONS

• SCONS is an awesome python-based build system/library. It's ages easier and you can basically configure your build setup as you wish, with minimal amount of work (it's python after all). I use scons in my personal projects and we have switched to it at work too, where we use it to build a huge project under linux/cygwin/msvc++. The only major downfall of it is the lack of detection routines, for projects you plan on distributing. Furtunatedly, nowadays you can detect most important libraries using "pkg-config".

• scons is no solution for the simple reason that an IDE won't be able to parse and understand such a make file.

• Autoconf is concerned with detecting platform variations before compilation begins. Scons is primarily a replacement for /usr/bin/make, specifying rules about the relationship between files.

• the current version of SCons added integrated support for autoconf-like functionality, starting with the ability to search for header files and libraries. It also provides a framework for adding your own tests, so you're not restricted only to what's available in the tool itself. The next version will add the ability to check for specific functions and types, and may add config.h-like header file generation, too.

CMake

• CMake is an open-source tool developed to stop the insanity. Before developing CMake, its developers had years of experience with autoconf. (...)
• CMake is a cross-platform build system that does everything that the auto* tools do, except that cmake works on ALL platforms, including Windows (with *and* without cygwin). On windows one has the option of generating several different flavours of Makefiles OR project files for MS Visual C++ 6 or MS Visual .NET.

Qmake

• Qmake I like the approach (and yes, I realise it's pretty much a Qt specific thing) taken by qmake. It seems to solve much the same problems as auto*, but without the pointless complexity.

• tmake from Trolltech tries to bite the problem from the other hand: it generates Makefiles based on a set of platform specific templates. What I like with it is that it is very simple to use, and can generate msvc (yes, I need that) project files. It is not extraordinalrily good but sufficient for my needs. It misses a few dependancies. I really regret that Trolltech has switched to a cpp based version in Qt3, the perl version was easier to hack.

Ant

• Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.

Autres

• MakeNG MakeNG is made by a fellow wxWindows user, a really cross-platform GUI framework (w/ threads, sockets, et al).(...) It *can* use Autoconf just fine, as my project, xMule, heavily demonstrates

• Dan Bernstein uses a very simple (shell scripts mostly) build system for his (small) packages. I think there was some documentation on his site, http://cr.yp.to.

• GConfigure It's not a completely mature package and may require some hacking to get working on your system, but there's nothing more satisfying than being prompted by a GUI to check off your autoconf options and after clicking ok, ending up with an RPM installed on your system.

• I would like to recommend buildtool-http://buildtool.sf.net/ (my own project ;) It can be used to write configure scripts and makefiles in a very easy way; it provides functionality like libtool and pkgconfig, plus some other minor things... It is a single, integrated tool, instead of multiple independant ones. And it does not generate files in the sense of auto* tools. Configure scripts and makefiles are kept short and simple and parsed at runtime.

• I can't say enough nice things about Jam. I use the Freetype version rather than the original (it nets me support for Windows 9x and junk). Basically, imagine Make, but with a whole bunch of builtin rules and portability already there, so you don't have to screw around with anything. It'll even work with Autoconf :)

• MakeXS The approach taken by MakeXS is to make it as easy as possible for the developer.

• Cooker Well, I might take this oppurtunity to announce my new project, cooker.

• package-framework Though `package-framework' do require the programmer to write `Makefile.in's, these are typically less than 3 lines for simple programs and libraries. Also, the system makes it really easy to bundle several libraries and programs into a big distribution and have them all configure and build in the right order, issuing only one command. The system was also designed from the start to build libraries and programs outside the source tree. package-framework is also designed to be non-invasive. The only thing it requires is a Makefile.in and a PLUGIN directory (itself containing 1-3 small files) in each directory containing source to be built.

• Personally, I have developed my own set of libraries hiding non-portabilities (skalibs), and build my software on top of it. Any portability problem is centralized in skalibs, and the build-time tests are understandable. I have no need for autotools, and I believe that no one has, either.

• boost.org uses its own make, bjam, which looks to me even more complicated than autoconf/automake. Like tmake, it is based on a set of platform-specific templates.