godard@GINOSKO.SAMSUNG.COM (Ivan Godard) (08/02/89)
In our application, we have a fairly large number of .h files which are kept in a release directory which is searched by the compiler when needed. While these .h files are fairly stable, occasionally one needs work. We copy the .h file to be changed into a working directory and modify it there, and do not modify the copy in the release directory untill the work directory contents is merged back into the release directory on the subsequent release of the software. Note that the each file name in the working directory will have a corresponding file in the release directory, although not vice versa. In this maintenance scheme, we want to have the compiler look first in the working directory (which is not the current directory) for a file it needs, and if it fails (implying that the sought file is not currently being worked on), to look in the release directory. With other compilers we achieved this by specifying (using '-I') the working directory before the release directory on the command line: 'g++ -i working -i release foo.c'. With the GNU preprocessor we have been getting odd and inconsistant search results using our directory scheme. Sometimes an include file came from the working directory, sometimes from the release directory. We looked at the preprocessor code, and found that apparently as a first step in locating a file to be included, the preprocessor searches its internal stack of expansions. If it finds a file name (from an outer include) it strips the directory part of that name and adds that to the search list for resolving the new include. The effect of this process is to look first (to resolve an include) in the directory of the file which is doing the include. Such an action is not unreasonable, as that is probably the most likely place to find the file, and so wasted trial opens can be avoided. However in our case, if a changed .h (in the working directory) is included by an unchanged .h (in the release directory) we will get the unchanged version from its copy in the release directory rather than the one we wanted. Now the standard says the places to look as implementation defined, and you guys are the implementors. Consequently the search behavior is not categorically a bug even though it prevents us from using a reasonable project organization. However, if you think that the way it works now is the way it should be, please document this behavior in the manual and call it a feature, and remove the claim at the bottom of manual page 17 that says that searching is under precise control. Sincerely, Ivan Godard (508)685-7200 X116