Is <http://www.gamesfromwithin.com/articles/0509/000100.html>
approximately still right?
The conclusions seem rather disappointing.
I can see a couple of possible objections: Jam seems not quite as dead
as advertised, in that ftjam seems to have had a recent release.
Maybe not with significant changes, but it suggests it's still used.
And CMake seems newish.
The article doesn't mention CMake, which (if I understand it
correctly) is to be used in building KDE4. I must admit it looks
nice, except that that makefile output seems to suck: the result uses
recursive make (which is one thing I'd like to remove, if I can), and
it seems to have an extra level (subdirs are in a submake, but each
object file seems to be done using a separate make).
<http://www.cmake.org/Bug/bug.php?op=show&bugid=944> happens to affect
the tree I'm thinking about: we have quite a few such generated
headers, and one of the problems with our existing build system (an
unholy combination of shellscripts and recursive make) occasionally
means someone integrates a change that leaves the tree unbuildable
from clean (because there's a header that turns out to be required
before it can be generated, but the developer didn't notice because an
old generated file was in their tree). So altogether maybe CMake
isn't right for us.
Shame about Boost Build v2,
<http://www.boost.org/tools/build/v2/index.html>. The documentation
looks of good quality (much better than it was whenever I last looked
at it). But the above article seems right that it's slow.
My instinct says SCons (or Rant, Bras, etc.) are basically the right
way to do this: use a DSL based on an interpreted language to describe
dependencies, files, etc., and once you've done that it ought to be
fine to use the scripting language to do the actual build, too. Shame
they seem so slow (relative to recursive make).
Is it just they're trying to do too much? If I built such a system
targeted specifically at our tree, with the kinds of things we want to
do (but without support for checking out from CVS/SCCS and so on,
which we don't want), would I end up with something that would be
suitably fast? I guess it's possible, but not all that likely: SCons
has been around a while, and was developed by people who know what
they're doing. Maybe it's something about Python? Maybe Lua (fastest
scripting language, according to some dubious benchmarks) would work
better?
CMake has been around for ages (since about 2001)... it just hasn't had a
higher profile as other systems.
Quote:
The article doesn't mention CMake, which (if I understand it correctly) is to be used in building KDE4.
Yep. (and Inkscape.)
Quote:
I must admit it looks nice, except that that makefile output seems to suck: the result uses recursive make (which is one thing I'd like to remove, if I can), and it seems to have an extra level (subdirs are in a submake, but each object file seems to be done using a separate make). <http://www.cmake.org/Bug/bug.php?op=show&bugid=944> happens to affect the tree I'm thinking about: we have quite a few such generated headers, and one of the problems with our existing build system (an unholy combination of shellscripts and recursive make) occasionally means someone integrates a change that leaves the tree unbuildable from clean (because there's a header that turns out to be required before it can be generated, but the developer didn't notice because an old generated file was in their tree). So altogether maybe CMake isn't right for us.
You might be able to get CMake to work around your dependency problems...
its a lot better than it used to be with those kinda things... it really
depends how complex your build process is as to whether it will have
problems.
On the plus side, CMake is actively developed, and its mailing list is full
of helpful people.
Is <http://www.gamesfromwithin.com/articles/0509/000100.html> approximately still right?
It seems to me that this article focuses on performance only. This is IMHO a
bad thing to do. When evaluating a build tool, I would look at how reliable
it can do incremental builds. In my eyes, this disqualifies all tools that
solely depend on timestamps, like GNU make, Jam and others.
Quote:
The conclusions seem rather disappointing. I can see a couple of possible objections: Jam seems not quite as dead as advertised, in that ftjam seems to have had a recent release. Maybe not with significant changes, but it suggests it's still used. And CMake seems newish.
Since CMake creates makefiles for GNU make, it disqualifies as well.
Quote:
The article doesn't mention CMake, which (if I understand it correctly) is to be used in building KDE4. I must admit it looks nice, except that that makefile output seems to suck: the result uses recursive make (which is one thing I'd like to remove, if I can), and it seems to have an extra level (subdirs are in a submake, but each object file seems to be done using a separate make).
Yes, for me, recursive make is also a killer.
Quote:
My instinct says SCons (or Rant, Bras, etc.) are basically the right
I looked at SCons also, but it turned out that I don't like Python (using
indentation as part of a languagues syntax is a no no).
Maybe Cons would be an option, it's Perl based.
However, I ended up using makepp (or make++), because of:
1) Written in Perl.
2) Uses MD5 checksums to find out what to rebuild *)
3) Has builtin dependency parsers for C/C++
4) Due to 1) can be easily extended using Perl functions.
*) makepp uses those checksums for source files, derived objects and even
the build script, so it will recognize a change in compiler options and
rebuild accordingly. The absence of the latter disqualified cook, which
uses checksums for sources and DOs only.
However, I ended up using makepp (or make++), because of: 1) Written in Perl. 2) Uses MD5 checksums to find out what to rebuild *) 3) Has builtin dependency parsers for C/C++ 4) Due to 1) can be easily extended using Perl functions.
5) Has GNU make compatible syntax.
6) Many more ;-)
Quote:
*) makepp uses those checksums for source files, derived objects and even the build script, so it will recognize a change in compiler options and rebuild accordingly. The absence of the latter disqualified cook, which uses checksums for sources and DOs only.
Since CMake creates makefiles for GNU make, it disqualifies as well.
Ah, OK. I hadn't looked too much at the details. That might well be
a problem for us. (We occasionally have source customers who prefer
not to install things like GNU Make, for whatever reasons.)
Quote:
The article doesn't mention CMake, which (if I understand it correctly) is to be used in building KDE4. I must admit it looks nice, except that that makefile output seems to suck: the result uses recursive make (which is one thing I'd like to remove, if I can), and it seems to have an extra level (subdirs are in a submake, but each object file seems to be done using a separate make). Yes, for me, recursive make is also a killer.
Yeah, but I can sort of go along with that. It was the extra level
(where having recursed to a directory, *that* makefile recurses to
actually build things) that really hit me.
Quote:
My instinct says SCons (or Rant, Bras, etc.) are basically the right I looked at SCons also, but it turned out that I don't like Python (using indentation as part of a languagues syntax is a no no).
I must admit I don't care about that. Emacs does the indentation
fine, and in practice it doesn't seem a problem.
It was really the lack of speed: on the test given on the web page, it
takes about 40 seconds or so to notice that nothing has to be done, vs
less than 2 seconds for recursive make to go through its build (also
doing nothing). (And that's after telling SCons that its cache
dependencies are correct, and to use timestamps.) That suggests
something's not right.
[...]
Quote:
However, I ended up using makepp (or make++), because of: 1) Written in Perl. 2) Uses MD5 checksums to find out what to rebuild *) 3) Has builtin dependency parsers for C/C++ 4) Due to 1) can be easily extended using Perl functions. *) makepp uses those checksums for source files, derived objects and even the build script, so it will recognize a change in compiler options and rebuild accordingly. The absence of the latter disqualified cook, which uses checksums for sources and DOs only.
Yeah, I should look again at makepp. Last time I looked was years
ago, and this time I should give it more attention. We already use
openssl, which (IIRC) requires perl to build, so using makepp wouldn't
add much dependency.
I looked at SCons also, but it turned out that I don't like Python (using indentation as part of a languagues syntax is a no no).
I must admit I don't care about that. Emacs does the indentation fine, and in practice it doesn't seem a problem.
How does emacs know where your python for-loop ends? That's what I meant
with "indentation is part of the syntax". Python determines what belongs to
a loop via indentation, not via brackets, begin...end or something like
that.
I looked at SCons also, but it turned out that I don't like Python (using indentation as part of a languagues syntax is a no no).
I must admit I don't care about that. Emacs does the indentation fine, and in practice it doesn't seem a problem.
e How does emacs know where your python for-loop ends?
In general, it doesn't, so you have to press backspace once to end the
block. It knows things like 'return' and 'break' tend to end an indentation,
and jumps out accordingly. In practice, the little help you get is enough
for comfortable editing.
IMHO, Python's block-by-indentation is a pain, but for different reasons.
Try merging two versions of a file, where one has caused a big chunk of code
to end up one block-level deeper ...
How does emacs know where your python for-loop ends?
It doesn't, of course, so I have to tell it. But then I have to press
the "}" key, or type "end" or "done" or whatever in other languages.
It's a problem for cut and paste and the like, of course. Similarly,
I imagine there could be problems with version control systems (either
merges succeeding incorrectly or failing when they might succeed).
I was just commenting that in reality I don't find it much of a
problem in the little Python that I do. Other people seem to find the
same. Of course, Python is unusual rather than unique.
In at least one language (Haskell) one can use either indentation or
more conventional braces and things. My impression is that most
people use indentation (though I've mostly read about Haskell in
tutorials and things, so that may be unrepresentative of real code).
Bringing it more back on topic, the trickiest merging problem I had
was when merging a longish running CVS branch, because bits of the
mainline had changed indentation causing conflicts (when really all
that had changed was indentation). But that was C and C++, not
Python.
I looked at SCons also, but it turned out that I don't like Python (using indentation as part of a languagues syntax is a no no).
I must admit I don't care about that. Emacs does the indentation fine, and in practice it doesn't seem a problem.
How does emacs know where your python for-loop ends? That's what I meant with "indentation is part of the syntax". Python determines what belongs to a loop via indentation, not via brackets, begin...end or something like that.
It put me off at first too, but in practice it doesn't cause problems.
But, back to the topic... I've been using SCons for a couple years now
and I am very, very happy with that decision. There are performance
problems that may (or may not) be acceptable to you and the rest of your
team.
But, being able to use a single, high-level, general-purpose scripting
language to describe the build is the biggest benefit in my mind.
Particularly when you're able to leverage it for all the other little
things the build system is asked to provide.
It put me off at first too, but in practice it doesn't cause problems. But, back to the topic... I've been using SCons for a couple years now and I am very, very happy with that decision. There are performance problems that may (or may not) be acceptable to you and the rest of your team.
Well, there's builds over the whole tree (whether full builds or
incremental), and there's rebuilds of the directory that contains the
files we're working on right now. The latter's what we overwhelmingly
do.
I'm inclined to think the apparent slowness of SCons wouldn't make
much difference over the whole tree. For one thing the tests off that
web site aren't representative of typical C++ code (ours almost always
include standard headers which will include templates and things), and
I suspect even our C code will be more expensive to compile (given
that all files include a few headers).
However, if I've changed a single file then doing "make" in that
directory works really fast, even if it's not necessarily quite as
safe.
Anyway, I suspect it would be a hard sell if the common case looked
much slower, as it should be. (I don't have any authority to impose
such a solution, and it's not the kind of thing that anyone would try
to impose anyway, I suspect.)
Quote:
But, being able to use a single, high-level, general-purpose scripting language to describe the build is the biggest benefit in my mind. Particularly when you're able to leverage it for all the other little things the build system is asked to provide.
Sure, that's how I feel too. Just a shame it's a bit slow. Similarly
with the significant difference between FTJam and Boost.Build.
My guess is I'll devise a little declarative format that can express
the things that we do in our Makefiles. Then that could be translated
reasonably easily into equivalents of what our existing Makefiles do,
or whatever other formats we want to try. That's not a perfect
endpoint, but it would be an obvious improvement on what we've got,
and it would more easily permit using new tools.
The MyLounge.com forum is intended for informational use only and should not
be relied upon and is not a substitute for any advice. The information contained
on MyLounge.com are opinions and suggestions of members and is not a representation
of the opinions of MyLounge.com. MyLounge.com does not warrant or vouch for
the accuracy, completeness or usefulness of any postings or the qualifications
of any person responding. Please consult a expert or seek the services of an
attorney in your area for more accuracy on your specific situation. Please note
that our forums also serve as mirrors to Usenet newsgroups. Many posts you see
on our forums are made by newsgroup users who may not be members of MyLounge.com
Term of Service
Build programs (replacing make(1))
Linear Mode
