Re: Alternatives to make
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:
On Apr 20, 10:12 pm, c...@mailvault.com wrote:
Although a little off topic, might I suggest reconsidering
for any sizable code base? What's wrong with make?
Which make? Almost every make I've seen is different.
About the only thing they have in common is the fact that
whether a line starts with a tab character or spaces is
significant, which I wouldn't consider something to be proud
of.
My company recently switched to Maven, and I regret it
every day. I miss Make's ability to do a single build on
multiple threads and being able to do the minimal build
necessary from current changes, aka actual incremental
builds.
Not all versions of make can use multiple threads (or
processes, which makes more sense). On the other hand, some
can use multiple machines, spreading the load through the
network.
Yes, standardize on a newer version of GNU Make and be done
with it.
That's what I do, for various reasons. But when you say "make",
I would generally interpret it to mean generic make; the common
subset which works in all (or almost all) makes. Regretfully,
that subset is pretty small, and very painful to work with.
(GNU make is Turing complete, and has a function which evaluates
the expansion of text, which means that it can be used to
implement a full fledged build system.)
As for the "minimal necessary build", I've never heard of a
make that could do that---change a comment in a header, and
either make will recompile everything which uses the header,
or it won't recompile things when you change something which
requires recompilation.
I'm sorry that Make is not magic. Yes, if you change a reader,
you should recompile all things which use that header. If this
becomes a significant burden, consider the pimpl idiom and
other such idioms expressly designed to lower such
dependencies and thus lower compile times for incremental
builds.
The compilation firewall idiom isn't really relevant when it
comes to changing a comment in a header.
It's quite imaginable to conceive of a system which really did
minimum recompiles---I believe Taligent was working on one when
they closed down, and I think Visual Age does this partially as
well. But it does suppose that the tool in question "know" C++;
that it be integrated with the compiler, more or less, which
isn't really the case for very many tools I know. Most of the
tools are, in fact, worse than make in this respect. (Boost
uses Jam, for example, which pretty much guarantees a less than
minimal compilation---some files that need to be compiled won't
be.)
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.
with a very, very primitive notion of "significant change",
Yes. I'll give you this "flaw" in Make. It only understands
"out of date" and "up to date", which may require some
additional user work to differentiate between other cases
where you don't need to rebuild some file from scratch and
only need to update it slightly. GNU Make understands this,
and provides things like .PRECIOUS to help facilitate that.
Even GNU make only works at the file level. In practice,
however, not all modifications of a header require the
recompilation of all sources which include it. (And I don't see
how .PRECIOUS is relevant to this.)
and historically depended on signficant user input to
determine dependencies (although most modern makes have
means of at least partially automating this, in
collaboration with the compiler).
Yes, that's the key to make a good Make build system for C++
code, automatic tracking of header dependencies. g++ as is
allows you to do this in one line of makefile. Otherwise you
might need to write a small script / program to act like the c
preprocessor to get all includes, but that's not terribly
hard, and probably available online. (See the Recursive Make
Considered Harmful paper.)
It takes a little more than one line. In fact, it takes some
collaboration from the compiler, and some shell behind it. But
it does work, and it works correctly (unlike most other tools
I've seen), because it depends on the compiler to find the
dependencies, rather than trying to reimplement the compiler's
logic internally.
--
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