Re: Alternatives to make
On Apr 23, 10:42 am, joshuamaur...@gmail.com wrote:
On Apr 22, 3:00 am, James Kanze <james.ka...@gmail.com> wrote:
On Apr 21, 8:42 pm, joshuamaur...@gmail.com wrote:
On Apr 21, 2:26 am, James Kanze <james.ka...@gmail.com> wrote:
On Apr 21, 8:48 am, joshuamaur...@gmail.com wrote:
Make's algorithm for managing this recompilation has a
very large granularity,
And that is the key. Recursive Make Considered
Harmful:http://aegis.sourceforge.net/auug97.pdf Make works
best at the highest granularity. This allows it to better
schedule things concurrently, among other things. The
paper describes it better than I can.
The paper is a good example of someone writing about
something he doesn't know or understand. But that's not the
point. The smallest granularity make can deal with is the
file---a file has been modified, or it hasn't. It can't
determine whether the modification will require
recompilation or not, because it doesn't know anything about
the files contents. So if you modify an inline function in
a header, all sources which include that header (directly or
indirectly) will be recompiled, and not just the sources
which use the inline function which was modified.
I agree that it may be possible to construct a better build
system that knows the C++ language to give better incremental
builds than GNU Make. However, what's wrong with that
paper?http://aegis.sourceforge.net/auug97.pdf (Well, besides
the "consider harmful" in the title.) Perhaps my understanding
is lacking as well, and I would like to hear differing
opinions.
Just that the author doesn't know anything about how to use
make. Or software engineering, for that matter:
-- It is very hard to get the order of the recursion into
the sub-directories correct. This order is very unstable
and frequently needs to be manually "tweaked."
Increasing the number of directories, or increasing the
depth in the directory tree, cause this order to be
increasingly unstable.
This is a basic software engineering issue. If you don't manage
your dependencies at this level, you're screwed. Recursive make
or not. But I've never seen an organisation so badly run that
this is a problem (and I've seen some pretty bad organisations
in my time).
-- It is often necessary to do more than one pass over the
sub-directories to build the whole system. This,
naturally, leads to extended build times.
This is related to the above. Again, I've never seen any
software so badly organized where this was the case. (Take a
look at any of the open source projects. They all use recursive
make, and none of them have this problem.)
-- Because the builds take so long, some dependency
information is omitted, otherwise development builds
take unreasonable lengths of time, and the developers
are unproductive. This usually leads to things not
being updated when they need to be, requiring frequent
"clean" builds from scratch, to ensure everything has
actually been built.
If you're using make correctly, dependencies are generated
automatically (see else thread). So nothing will ever be
missing. And the only times I've seen the need for clean builds
due to mishandling of dependencies was due to template
instantiations in the repositories not getting rebuild when
needed---a problem with the compiler/linker, not with the make
and its dependencies.
Basically, the paper argues that if you screw up your project
management beyond belief, recursive make doesn't work. Which is
true, but then, nor does anything else.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34