Recursive #includes
Leo de Wit
leo at philmds.UUCP
Mon Feb 27 22:07:46 AEST 1989
In article <573 at marob.MASA.COM> samperi at marob.masa.com (Dominick Samperi) writes:
|In article <9727 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|>It's easy to get the Makefile correct; just declare that a header
|>depends on the others that it #includes.
|
|The makefile that we are currently using is structured this way, and
|I suspect that this may be the reason that make (actually VMS MMS)
|takes forever to get started (i.e., go through the dependencies).
Another might be the fact that you're using MMS; we have a product that
has to be generated both for Ultrix and VMS, and could keep the
makefiles fairly system independent. MMS/CMS takes a lot of time to get
started, as compared to Make/SCCS. Another point: Although the claim is
that MMS is, except for some syntax additions, the same as Make, I
found out it treated macros differently.
|>Any such preprocessor is badly broken [i.e., one which does not permit
|>recursive includes]. K&R 1st Edition imposes no
|>such constraint. How about telling us what brands of compiler have
|>this problem...
|
|I'm working with the Oasis port of AT&T's C++ translator to VMS. Their
|preprocesor is named GCPP (could this be the GNU C preprocesor?). By
|the way, I couldn't find any comments about recursive includes in
|K&R, so I guess this means they are permitted?
As Dough said, unless it's broken, yes. Of course you have to do the
inclusion conditionally (or did you mean 'nested' instead of
'recursively' ?), since nesting can only occur up to an
implementation-defined limit (which must be at least 8, if I may
believe my - old - copy of the dpAns).
Leo.
More information about the Comp.lang.c
mailing list