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.)
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.)
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.
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.)
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.
' |