scs@adam.mit.edu (Steve Summit) (04/19/91)
One of the things you discover when you start writing a Makefile dependency generator (one that scans source files automatically for #include directives) is that you have to reimplement an uncomfortably large fraction of a full-blown C preprocessor to do so. (I handled #define and #ifdef, and fell back and punted when it came to #if.) Therefore, it becomes reasonable to inquire whether the "real" C preprocessor could be coaxed into helping out. To do so begins to encroach on the "Unix Philosophy" (each tool should do one job, and do it well), since helping to build Makefiles has not much to do with the task of preprocessing C source. In this case, I'd say it's justified, if not carried too far. In article <1991Apr17.003928.23530@news.iastate.edu> john@iastate.edu (Hascall John Paul) writes: > For those with Ultrix, you may want to check out the undocumented >(in my old docs anyhow) option "-Em", as in this simple-minded example: > > $(CC) -Em $(CFLAGS) $(DEFINES) $(CSOURCES) >>Makefile This is doubtless related to the cpp -M flag, which was introduced (I believe) by Berkeley. Though motivated by good intentions mirroring the discussion above, the behavior of this option, as implemented, goes too far. It's one thing to add an option to a preprocessor/compiler meaning "don't preprocess or compile; just emit names of #include files read." This is still within the "job" of preprocessing, if only marginally. It's quite another thing to have the names emitted via lines of the form <name-of-source-file-with-.c-replaced-by-.o> <colon> <included-file> This couples the preprocessor unnecessarily and unacceptably to the make utility's syntax. It would be far better simply to emit the #include lines themselves, or to emit lines of the form <name-of-source-file> <included-file> <flag> where flag indicates whether the #include used the "" or <> syntax (and perhaps whether -I, or a standard include directory, was involved). (Another clue that there's something wrong here: /lib/cpp /dev/tty works as expected, while /lib/cpp -M /dev/tty complains about a "missing component name on /dev/tty", because it can't replace .c with .o . cpp is not a general-purpose preprocessor, but it shouldn't be playing with filenames in this way.) If my objection were only philosophical, I'd stew quietly and not bring it up. However, while trying to make things convenient for a simpleminded >> Makefile build (but since when has Unix held your hand?), this overprocessed output format, by losing information, precludes alternate, more flexible dependency generation strategies. For instance, I like not to clutter my Makefiles with dependencies on the header files in /usr/include (if they ever change, one had better delete every .o file everywhere and rebuild everything), and to treat other <> dependencies (which typically refer to files in directories specified with -I) differently. In article <9734@star.cs.vu.nl> geels@cs.vu.nl (Arnold Geels) writes: >Gcc also has the -MM flag (exclude system >header files). This is (sort of) a step in the right direction, giving one a bit of control over the "" vs. <> distinction, but it's not fine- grained enough. Nothing derived from -M (as currently defined) could be; gaining full control requires taking a step back and having the "emit dependencies" option to the preprocessor emit the dependency information in a lower-level, unprocessed form. To be sure, doing so would require the insertion of an awk or sed script in even simple Makefile builds, but it would not be a difficult or complicated script. Changing ".c" to ".o", inserting colons, and making decisions based on strings ("" vs. <>) is those tools' job. Unfortunately, the current definition of the -M flag is a de facto standard now, and many, many Makefiles depend (sic) on it. I suppose I should have complained more loudly when 4.3bsd first came out; it's a bit late to be whining about it now. This has little to do with C; I've redirected followups to comp.unix.programmer . Steve Summit scs@adam.mit.edu
campbell@redsox.bsw.com (Larry Campbell) (04/20/91)
The SVR4 preprocessor has a -H option which generates the names of included files, with no other gunk attached. -- Larry Campbell The Boston Software Works, Inc., 120 Fulton Street campbell@redsox.bsw.com Boston, Massachusetts 02109 (USA)
guy@auspex.auspex.com (Guy Harris) (04/23/91)
>The SVR4 preprocessor has a -H option which generates the names of >included files, with no other gunk attached. That dates back, as I remember, to S5R2, at least.
itcp@praxis.co.uk (Tom Parke) (05/14/91)
guy@auspex.auspex.com (Guy Harris) writes: > >The SVR4 preprocessor has a -H option which generates the names of > >included files, with no other gunk attached. >That dates back, as I remember, to S5R2, at least. Its not in Pyramid's cc - its not hard to acheive the same with awk | sort | uniq which we do for generating make dependencies. -- Tom Parke (my opinions and spelling are strictly temporary) "Trust me - I'm a banker, and this is a metal detector." - Steve Bell itcp@praxis.co.uk