Re: [AD] build process overhaul

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sat, 2005-11-26 at 11:32 +1100, Peter Wang wrote:
> Getting rid of the dep* scripts is a good move.  I've been running
> make clean more often than necessary and letting ccache mop up.
> 
> Automake, I haven't had experience with but I've also read some not so
> nice things about it.  Well, try it and see I guess :-)  It still
> leaves our cross-platform build problems, though.

Yes, true - so it wouldn't be an optimal solution. My main motivation
for automake is that so many projects seem to use it, so it can't be
that bad..

> I don't like libtool.  The command-line is hidden under a layer of magic
> it's impossible to copy-and-paste erroneous commands from the terminal
> and retry them manually.  Add to that that it puts object files in
> hidden directories with weird extensions and you're in for a world of
> pain.  And it's slow.

Ah, maybe its use can be avoided. Just all the examples in the automake
docs use it. But can always leave in makefile.in parts in Makefile.am I
think, all I really want from it is the dependency handling anyway.

> I'm interested in your findings with scons.  Are there other tools we
> should look at too?
> 

Generally, I liked scons when I tried it - but when I started with some
simple examples, it wasn't quite as easy to make it build things as I
had hoped. But mainly, it's all minor things. For example, its
dependency scanning doesn't consider any preprocessor conditionals, so
e.g.:

#ifdef BLAH
#include "blah.h"
#endif

There it will make "blah.h" always a dependency. Maybe it's never a
problem, but I don't like it somehow.

I also found it a bit inflexible, for example I could find no easy way
to define the order of something. Like, first generate all built source
files, then start the main build. The introduction text claims you can
use "Nodes" or something, but there's no examples, and on their ML I was
told not being able to specify an order is by design and scons always
wants a complete build tree, and then determine the order itself. They
also showed me a workaround of using dummy files as fake dependencies..
but well, that didn't impress me. For Allegro, this probably is no
problem though.

And at last, I had hoped there would be some easy way to replace
aclocal.m4 and configure.in. Like, a repository of useful checks or
something. But as it looks, it all needs to be rewritten, simply using
python scripts insterad of m4. An improvement, but don't know, it is
somehow less than what I had hoped for.

-- 
Elias Pschernig