Include files in Local vs. Reference Directories

--- Background ---


It is common for a large software project to have several libraries
and applications under development in a common build hierarchy. In
order to share common code, projects establish central 'reference
copies' of source. They then develop Makefiles (or build scripts,
etc.) that first look in a local build tree, then look to the
reference build tree to resolve files.


CC ... -I$LOCAL_BASE/include -I$REF_BASE/include ...


Following the standard reccomendation for #include directives, "system
includes" use the #include <system_header.h> format while "project
includes" use the #include "project_header.h" format. The compiler
treats these include directives differently:


<bracket> style includes cause the compiler to reset the include scan
algorithm, looking to the -I paths to begin searching for the next
include file.


"quote" style includes cause the compiler to look in the current
directory (the one containing the current header file) before looking
to the -I paths.




--- Problem Statement ---


Assume we have a source file a.cpp that includes "a.h" and "a.h"
includes "b.h". If both of the header files are in the reference
directory, the compiler first locates "a.h" then looks in that
directory for "b.h", finding it at that location. If I now bring
a.cpp and b.h into my local build environment to make a change to
both, while referencing the directory that contains "a.h" and the
original "b.h", the compiler will not find the locally modified "b.h"
because it again finds the reference "b.h".


If the scenario is changed to have a.cpp include <a.h> and <a.h>
include <b.h>, the locally modified <b.h> is found.


An alternative is to either copy all header files into the local build
tree or to symlink all of the header files into the local build tree.
Both of these have pros/cons regarding consistency of practice in
setting up the local build enviroment and managing updates.


--- Questions ---


(1) What is the common practice for solving this problem?
(2) Are there significant arguments pro/con adopting the <bracket>
form for all includes, independent of the system vs. project
distinction?
(3) Is there a reccomended article or text that addresses large-scale
build environments that talk to this particular problem?




Thanks,


Chuck
[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]

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