|Include files in Local vs. Reference Directories email@example.com (2001-09-29)|
|Re: Include files in Local vs. Reference Directories firstname.lastname@example.org (2001-09-30)|
|Re: Include files in Local vs. Reference Directories email@example.com (2001-09-30)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||30 Sep 2001 22:41:50 -0400|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|Posted-Date:||30 Sep 2001 22:41:49 EDT|
email@example.com (Charles Proefrock) writes:
>--- 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?
Putting the reference files under version control (e.g., CVS), and
when you note that you need to change one of those files, checking out
a copy of the reference directory, doing the changes there, and
arranging (maybe through env variables) inclusion of files from your
copy instead of the canonic reference. Since your copy also contains
a.h, the right b.h is included.
>(2) Are there significant arguments pro/con adopting the <bracket>
>form for all includes, independent of the system vs. project
Con: I often want includes to work relative to the directory of the
including file. For non-system files everything else becomes messy
once you have more than one directory. That bash does not provide
this feature (at least last time I looked) is one of its worst
M. Anton Ertl Some things have to be seen to be believed
firstname.lastname@example.org Most things have to be believed to be seen
Return to the
Search the comp.compilers archives again.