Re: #include what?

Chris F Clark <cfc@shell01.TheWorld.com> writes:
[Someone wrote:]
>> For #include "foo" gcc searches the directory containing the current
>> file and then falls back to the <foo> rules.
...
>Next, you seem to have some confusion about what "current directory"
>means.


He described exactly what's happening. I don't see any confusion
there.


>Generally, "current directory" now means, the directory containing the
>file which has the #include statement inside it. That is if you have
>a source file called "/source/text.c" that has done an include of
>"foo.h" and that has gotten resolved to "/include/lib/foo.h", then the
>current directory for #include statements within foo.h is
>"/include/lib/" and for #include statements in "text.c" is "/source/".


This is as it should be.


>However, this was not always the case. In the pre-gui days, when
>everyone did command line programming in something akin to a "shell".
>The OS/shell kept a concept of the "current directory" (originally in
>Multics it was called the "current working directory")


In Unix this is called the "working directory", e.g., in pwd(1) (or
also the "current working directory", e.g., in getcwd(3)).


>and all file system commands that didn't specify a complete path
>(i.e. "foo.c" as opposed to "/source/foo.c") were resolved as
>references in (or relative to) that current directory.


On such systems the file processed when including such a relative file
name depends on the current working directory, which is usually not
what the programmer intended. The programmer usually intends to
specify a specific file. So this behaviour usually makes it necessary
to compile the including file from a specific working directory,
otherwise the compilation will not work as intended. Of course, if
the including file A is to be included in a larger project B, B may
have a different idea what the working directory should be than A; you
will certainly have fun if the larger project has to include two files
with different working directory requirements.


So, letting relative filenames refer to the working directory makes
relative filenames unusable for the usual purpose. Absolute file
names are also not really usable, because they require the installer
(the person who compiles the program) to unpack the package and its
components in exactly those places where the original programmers had
them; with components coming from different programmers, this would
lead to distributing the package throughout the file hierarchy.


So, overall, letting relative filenames refer to the working directory
is a bad idea.


>[...]the current directory is the one which holds the original source
>file I started processing


That is also a bad idea. Then the including file will work as
intended in a project with one directory structure, but not in one
with a different structure.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html

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