|#include what? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-04-25)|
|Re: #include what? firstname.lastname@example.org (Russ Cox) (2006-04-26)|
|Re: #include what? email@example.com (Ian Lance Taylor) (2006-04-27)|
|Re: #include what? cfc@shell01.TheWorld.com (Chris F Clark) (2006-04-27)|
|Re: #include what? firstname.lastname@example.org (glen herrmannsfeldt) (2006-04-28)|
|Re: #include what? email@example.com (2006-04-28)|
|Re: #include what? cfc@shell01.TheWorld.com (Chris F Clark) (2006-04-30)|
|Re: #include what? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-09)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||28 Apr 2006 23:49:45 -0400|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|References:||06-04-148 06-04-150 06-04-154|
|Posted-Date:||28 Apr 2006 23:49:44 EDT|
Chris F Clark <cfc@shell01.TheWorld.com> writes:
>> 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"
He described exactly what's happening. I don't see any confusion
>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.
M. Anton Ertl
Return to the
Search the comp.compilers archives again.