Re: Make, make, make. . .

[Keith Lucas <keith@fysh.org>]

> The project I run at work has around a million lines of C++ code - organized
> for human's benefit with no special thought of how to help make do it's stuff.
> It compiles in about a half hour if you touch everything and well under a
> minute if you touch a single file which has no other dependencies.  That's
> good enough for me.


The multi-million line project I just finished working on was
organised in a similar "human-usable" format. I can only assume from
that that I'm not a human, because I didn't find it very usable.

The make system was best described as fantastic. I've never seen
anything like it in all my born days.

Each sub-project has a makefile, each project has a makefile which
recurses over the sub-makefiles. Some of the projects depend on each
other as well. So every developer ends up with a script that builds
the projects, usually their own which may or may not build things in
the right order. The source is being changed by ~100 people all at the
same time. Some of it is machine built using other projects. Some of
it is written in config files that are re-interpreted by tools.

Because they didn't think very carefully about this stuff, their DAG
is broken. The build scripts rely on multiple passes across the source
to generate everything correctly. So basically, every so often you get
these "odd" problems, with things linking incompatible stuff that gets
solved by a complete re-build which only takes about TWO HOURS to just
check what needs recompiling.

By contrast, it only takes about 2 1/2 hours if it needs to build
everything.

I can counter every example of "a foo that happens to work" with a "a
foo that didn't" example. If your dependency graph has breaks in it,
you're at risk from finding that every time you add a dependency. That
you haven't hit the problems yet doesn't mean you will, but it doesn't
mean you won't. And finding it means something might not build right
but might not generate the right errors either..

It's like the difference between testing the program by running it a
few times with different data, and using a mathematical verification
to show there are no defects.


---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk