Re: #include what?

I wrote:
>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")


Anton Ertl replied:
> 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.


This may be true in 20/20 hindsight, based on current conventions.
However, in the early days (not that I was there at the start of
either the Multics or Unix projects, but I was around pre-the modern
interpretation and worked with and was taught by people who were), we
understood the concept of working directory and used it to specify
exactly what we meant. That is in fact, why it was called a "working"
directory. It was the directory containing the project you were
working on. If you were working on another project, you were working
in another directory.


The point being, that if you specified a filename that wasn't an
absolute pathname, the compiler has to pick somewhere to look for the
file. The obvious choice on systems that support a "current working
directory" is to attempt to open the file in the current working
directory, which is what a call to fopen when given a non-absolute
pathname does. Moreover, since the common convention was to cluster
all the files of one project into one directory, making that directory
the working directory and using the default fopen behavior works quite
well. Moreover, it is simple to document and matched the programmers
intuition of the time.


This is not to dispute the genius of the modern interpretation, that
the "current directory" of a file should be the directory containing
the file. That is a better solution in most ways.


However, it was non-obvious and when I first encountered compilers
that used the new rule (which occurred prior to the ANSI standard for
C) the compilers seemed broken because they did unusual things that
defied the common convention. For example, you couldn't make a copy
of a header file in the local directory and then hack it to override
some behavior you wanted localized. Moreover, if you reordered your
include statements, sometimes you would change where you picked up
certain header files from, if you had copies in multiple directories,
because the first file which referenced the header file might be in a
different directory making that directory the "current" one. With the
old rules, the compiler always searched for header files in the same
sets of directories in the same order, where one include file was
found had no impact on where the include statements within it were
searched.


So, while the original convention for include files using "current
working directory" may not make sense to modern sensibilities, it did
have its own logic and those of us who were used to the old style had
features of the old style that we lost with the modern interpretation.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
[My recollection agrees with Chris'. While it now is clear that the
name of a nested include is interpreted relative to the enclosing
file, it took us a while to figure out that anything else produces
results that are too surprising. -John]

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