Re: Include files in Local vs. Reference Directories (Anton Ertl)
30 Sep 2001 22:41:50 -0400

          From comp.compilers

Related articles
Include files in Local vs. Reference Directories (2001-09-29)
Re: Include files in Local vs. Reference Directories (2001-09-30)
Re: Include files in Local vs. Reference Directories (2001-09-30)
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: 30 Sep 2001 22:41:50 -0400
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 01-09-127
Keywords: C, practice
Posted-Date: 30 Sep 2001 22:41:49 EDT (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

- anton
M. Anton Ertl Some things have to be seen to be believed Most things have to be believed to be seen

Post a followup to this message

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