Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!star.cs.vu.nl!versto From: versto@cs.vu.nl (Verstoep C) Newsgroups: comp.lang.c Subject: Re: C + Make Message-ID: <7587@star.cs.vu.nl> Date: 18 Sep 90 09:06:06 GMT References: <0949@sheol.UUCP> <26567@mimsy.umd.edu> Sender: news@cs.vu.nl Lines: 36 chris@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@cs.vu.nl)