gcc -Iinclude src/*.cpp src/*.c tools/httpd.cpp -o httpd

The magicmakefile by definition only works for platforms that I care about.

I have yet to see autotools work for compiling a project in the following situations:

* an application for the Cell processor with tasks running on the SPE as well as the SPU (different compiler required)

* software compiled by various DSP compilers where you really do need to have different optimization options set on different source files in order to have a correct executable – and not just to avoid compiler bugs either.

* software that works on 64 bit windows compiling with the Microsoft SDK – which is required since GCC/G++ v4 is not yet compliant with the requirements of WIN32 and WIN64 and most importantly S.E.H.

* software running on iphone where the executable not only needs to be cross compiled but also needs to be cryptographically signed.

* software running on mac os x or debian linux or redhat linux or windows where you need to create a full featured pkg, deb, rpm, or msi installer file.

* software running on mac os x where you not only need to do cross compiling but the cross compiling for multiple platforms is done by the same gcc invocation, ie: ‘-arch i386 -arch x86_64 -arch ppc -arch ppc64′ but in this case you must use different tools to manage static libraries.

In all these situations, the best practice is to either make your own hand built makefile, or xcode project, Wix project, or Visual Studio 2008 solution file – So it is best to organize your project so that it is very simple to do any of these things. What I did with the magic makefile is to make the typical linux/mac os x command line tools and libraries automatic and any other special case platforms are easy to manage due to simple project layout.

Regards,
Jeff Koftinoff

Ideally, it would be nice to list a long list of requirements and properties of various build/config systems and then basically figure out how all competitors do in all the listed aspects. I mean, I think we must accept that there will be no obvious winnner for everyone, but done right a comparison document would still help everyone interested in this.

Getting to your idea about writing a comparative text on the various build systems. It’s a great idea and a needed one.

I think a good starting point would be to start listing the requirements on such a build system.

* easy to use for end user
* cross compiling possible
* easy to split configuration files and programs into separate dirs
in the resulting installable file

stuff like that, perhaps a bit more specific Have you started such a list?

/hesa

… it doesn’t take long before one comes to the insight that different programs (or rather languages) and target platforms may have different requirements. But we can twist that around again and think about the quick increase in speed/mem of new devices so I think that we have to think about all programs to at some time execute in a “small device”.

I’d say that autoconf’s weakest points are its arcane syntax and the fact that it requires a POSIX shell etc.

But of course, each project has its own set of needs and requirements and what suits one project perfectly might not at all suit the next…

the latest version is at http://opensource.jdkoftinoff.com/project/projects/magicmake/wiki

and the previous version with more info is at:
http://opensource.jdkoftinoff.com/jdks/trac/wiki/MagicMakefileV5

By the way, recently I had to do some java work and ended up using Maven2 – A big departure from normal build systems. Unfortunately is very integrated with Java – but the kinds of things it does is very worthwhile like managing both direct and transitive dependencies, source code layout by convention, no need to modify any files when you add source files, etc. Plus it integrates amazingly well with continuous integration tools like hudson. There is nothing like it for C and C++ projects.

jeffk

My experience is actually rather that autoconf is the best of the available options for making build systems that are cross-compile friendly. But admittedly that’s biased by my own skillset.

My solution is to organize my projects extensively. Every project creates one library. The headers go in an ‘include’ directory. The sources for the library go in the ’src’ directory. Tool programs and test programs and single source files and are linked with the library and live in a directory called ‘tools’ or ‘tests’ respectively.

Once you do this, it is easy to hand create a Makefile for any unix like platform. It is easy to create an xcode project. it is easy to create a visual c++ project. A 4 line qmake pro file can be used with wildcards for qmake.

Once you lay out your project’s files in a logical way it is always easy to regenerate your project’s build script.

The reality is that a single tool can not support all the platforms at once – The typical architectures needed are too diverse like Mac OS X universal binaries, iphone, Windows7, and various forms of Embedded Linux.

I have seen autoconf/configure scripts break so often in these different configurations that I do not trust it anymore. Portability is hard and there is no silver bullet except to have a continuous integration tool performing compiles on all supported platforms.

–jeffk++