C + Make

[Verstoep C]

chris at mimsy.umd.edu (Chris Torek) writes:

>Indeed.  Unfortunately, this requires the construction engine (`make')
>to have access to the actual dependency information, which means either
>pushing all those rules from mkdep-* into `make' itself, or else an
>incestuous relationship between the compiler(s) and `make'.

In fact, this is done in Amake, the configuration management tool for
the Amoeba OS.  Besides offering parallellism, it allows it to define
that a tool publishes the inputs it has read during an invocation.
This information is automatically merged in a `statefile', which also
maintains information about compilation flags used.  As the C-preprocessor
is most of the time available as a seperate program, it is easy
to `plug in' a slightly enhanced version, which also reports the header
files encountered.  (As a last resort, the "cc-c" tool can be defined
to use a "mkdep"-like program, but on average we have measured a 20%
overhead in that case.)

>(Too, it has the drawback of requiring that there be room in every
>output file for the information needed by `make', or else that output
>files come in pairs: foo.o and .depend.foo.o, or some such.  Which is
>`better' is to some extent a matter of taste.  One can argue that every
>`object' file should in fact be a directory: foo.o/text, foo.o/data,
>foo.o/symbols, foo.o/debug, foo.o/depend....  Let the file system work
>for you.)

In amake, these files are kept seperately, in a subdirectory.  They are
completely hidden, and temporarily moved back when they are needed
(i.e., when the loader or archiver are to be run).  The statefile contains
the mapping of tool invocations to the objects produced, so it knows which
ones to pick, during a rebuild.  Afterwards, only the target objects are
directly visible. The sources and source descriptions are usually kept
elsewhere, so that several independent (mc68000/sparc/vax; Amoeba/Unix)
configurations can be conveniently maintained.

Kees Verstoep (versto at cs.vu.nl)