Best Build Tool for large C projects

[scholz.lothar]

What is the best build tool for somebody who want to get rid of make.
I'm looking for something with the following features:

1) Must scan the files for dependencies.

2) Results from 1 must be safed so that not each invokation is doing a
complete scan because the files may be on a NFS with slow connections.

3) Should do a preprocessing run and check if there are real changes.
If i change code

4) Collects compile optinos in a database/central location so i don't
need to set them in a lot of
build files.

5) Works well with multiple CPU's/Core's and ideally detects the
number of available CPU's
automatically. Running it on a nightly build machine with 1 cpu or a
developer machine with 8.

6) As 5 suggests. I need a good split into independent dependency
targets. Aka "make -j"

7) Does not need huge requirements to work: No Java solution (and no
Perl). ANSI C with a few Posix/Plattform Hacks would be best. But ruby
or python based are also okay.

8) Helps me to avoid autoconfig/automake hell.

9) Available on WinXP/WinVista/FreeBSD/Linux/NetBSD/OpenBSD/Solaris/HP-
UX/MacOSX is required. All in 32 and 64 bit modes (BSD's and Linux
will hot have a 32 bit library installed)

10) Fast.

11) Little typing.

I heared about jam and will start reading the docs tomorrow. So please
comment. I only worked with make in the past.

 

[Border]

You can try scons. http://www.scons.org/
Scons is an Open Source software construction tool—that is, a next-
generation build tool. Think of SCons as an improved, cross-platform
substitute for the classic Make utility with integrated functionality
similar to autoconf/automake and compiler caches such as ccache. In
short, SCons is an easier, more reliable and faster way to build
software.

- Bian Jiang

 

[Laurent Deniau]

What is the best build tool for somebody who want to get rid of make.
I'm looking for something with the following features:

I should say that a couple of months ago I had exactly the same
question for my COS project except that I had one more strong
constraint that none of the existing tools could fulfill (AFAIK)
except make itself...

I wanted to provide not only makefiles to configure, build and install
COS but also for the future COS' users projects (to simplify, COS
needs a two-steps linking phase). The goal was to help them to write
their own project makefiles on top of the COS makefiles very easily.
The result is that COS does not come only with headers and libs (COS
is a C library), but also with makefiles that you can find in

http://cos.cvs.sourceforge.net/viewvc/cos/CosBase/include/cos/

prologue
epilogue
mak/*
cfg/*

It requires gmake which is very efficient and portable. It focus on
COS but the structure is very flexible and it could even be simplified
for "normal" C projects. A user makefile looks like

include cos/prologue

program = myprog

include cos/epilogue

Almost all the rules and variables are configurable either by setting
lowercase variables equivalent to their uppercase version used
internally or by defining pre and post rules rule.pre and rule.post
for rules that you want to customize. As I said, COS itself uses these
makefiles despite of its particular needs. Actually I only have access
to various Linux and MacOsX but the cfg/* files are very similar to
the POCO (C++ POrtable COmponents) config makefiles which is available
on many platforms. It is able to build debug, profile and release
version (all by default), archive and shared libraries (all by default
if available on the platform), manage testsuites and is multi-
platform.

From 1st Paul's rules about GNU make:
"Don't hassle with writing portable makefiles, use a portable make
instead!"

What is nice with gmake, is that you can extend the rules easily, no
black magic. If you need more functionalities, you can use the gmsl
(GNU make standard library) which basically provides the functions
found in perl/python/etc alternatives.

Hence hereafter I consider gmake

1) Must scan the files for dependencies.

this is more related to compilers options for automation, and a simple
rule does the job for including properly automatic dependencies
computation.

I haven't seen any problem with gmake there.

2) Results from 1 must be safed so that not each invokation is doing a
complete scan because the files may be on a NFS with slow connections.

no idea if gmake is slow on that point but locally, its pretty fast.

3) Should do a preprocessing run and check if there are real changes.
If i change code

a simple rule using md5 or equivalent does the job on top of
dependencies

4) Collects compile optinos in a database/central location so i don't
need to set them in a lot of
build files.

in my case, installed with COS in include/cos/cfg/*

easily customizable either for global use or on a per project basis.

5) Works well with multiple CPU's/Core's and ideally detects the
number of available CPU's
automatically. Running it on a nightly build machine with 1 cpu or a
developer machine with 8.

gmake ?

6) As 5 suggests. I need a good split into independent dependency
targets. Aka "make -j"

gmake ?

7) Does not need huge requirements to work: No Java solution (and no
Perl). ANSI C with a few Posix/Plattform Hacks would be best. But ruby
or python based are also okay.

idem for me ;-)

8) Helps me to avoid autoconfig/automake hell.

I don't like the autoconf approach.

9) Available on WinXP/WinVista/FreeBSD/Linux/NetBSD/OpenBSD/Solaris/HP-
UX/MacOSX is required. All in 32 and 64 bit modes (BSD's and Linux
will hot have a 32 bit library installed)

my makefiles assume a moderately compliant posix environment (since
make relies on sh).

10) Fast.

gmake ?

11) Little typing.

3 lines for common C project

I heared about jam and will start reading the docs tomorrow. So please
comment. I only worked with make in the past.

Well, if you find some tools which are as simple and powerful as
gmake, widely available and widely known by C programmers and which
allows to provide customizable templates for users project (very
important), I will also be interested. I am not sure that the result
would be more flexible, simpler or shorter than my makefiles but I
would gave it a try.

a+, ld.