Re: Include files in Local vs. Reference Directories

cwp1875@hotmail.com (Charles Proefrock) wrote:


((complex problem with include files))


> (1) What is the common practice for solving this problem?


Well, you've just shown me one of the reasons why the system I work on
is set up the way it is. It's wildly nonstandard, and involves running
our own pre-preprocess stage before invoking the C compiler, but it
works, overall, like this.


Each .c file has an associated .h file, which contains the typedefs,
functions, etc, exported by that .c file.


The system is divided into a number of "modules", with between 1 and about
150 .c files, each with its associated .h file. Each module has a
subdirectory in the source tree, which holds the .c and .h files - there
is no overall /include directory, and the only headers which are
<included> are the system ones.


A .c file may #include .h files corresponding to other .c files in the
same module. They're done by


#include "mod_a/file_a1"
#include "mod_b/file_b42


And the compile line says -I/dir/with/module/dirs/as/its/subdirectories


A .c file may NOT include .h files corresponding to .c files in other
modules. It may only import the module's .h file, which contains extracts
from the .h files of the module.


When #including a .h file requires another .h file, both are #included in
the .c file.


All these rules, and the second-plus-level imports, are taken care of by
our own pre-preprocessor, which is the key to enforcing this system.


> [I had the same problem when we were porting Lotus 1-2-3 to Unix about
> 10 years ago. I ended up adding a switch to the preprocessor to change
> the search order. -John]


Makes sense. I think we still have a copy of 1-2-3 for VMS somewhere on
the shelf...


---
John Dallman jgd@cix.co.uk
                    "C++ - the FORTRAN of the early 21st century."

Return to the comp.compilers page.
Search the comp.compilers archives again.