Allow "" and <> search paths to be different in CPPScanner

[bdbaddog]

This issue was originally created at: 2009-08-27 14:20:17.
This issue was reported by: gregnoel.

gregnoel said at 2009-08-27 14:20:17

The CPPScanner uses the same search path for "" and <> #includes. Moreover, the CPPScanner will search '.' if the include is not found elsewhere (which isn't even always correct for a "" search).

This issue is to look at the semantics provided by the the most common compilers (GNU and MSVC at a minimum) and see if there is a way to capture their semantics in a common way (maybe a LOCALCPPPATH that is searched before CPPPATH or maybe a special token that causes the directory of the source file to be searched, or maybe even both).

gregnoel said at 2009-08-27 14:23:20

Add Sergey as CC.

gregnoel said at 2009-12-09 12:03:44

Bug party triage. In the short term, separate the processing for ".." and <..> so that only ".." names are evaluated relative to the file that includes them. After that is fixed, reassign as future p3 to allow separate specification of the ".." and <..> paths.

gregnoel said at 2009-12-16 17:06:46

*** Issue #2524 has been marked as a duplicate of this issue. ***

gregnoel said at 2009-12-16 17:09:42

Issue #2524, just marked as a dup of this issue, has an excellent example of a ".." relative path that should work even if CPPPATH does not contain the directory.

gregnoel said this issue is duplicated by #2524 at 2009-12-16 17:06:47.

[ravenAtSafe]

As a way of voting for this issue I'll attach a repro (g++ 7.5.0, scons 3.0.1) that demonstrates how this results in incremental build mistakes.

1. patch < repro_base.patch
2. scons
   Will be correctly successful
3. patch < repro_bad.patch
4. scons
   Will incorrectly say all targets are up to date
5. rm test.os
6. scons
   Will correctly error

sconsIncludeRepro.zip

[mwichmann]

To answer the "standards question", the C standard leaves the #include search as an implementation detail. So there's no absolute answer, but consistency.

MSVC

Quoted form:

1. In the same directory as the file that contains the #include statement.
2. In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files.
3. Along the path that's specified by each /I compiler option.
4. Along the paths that are specified by the INCLUDE environment variable.

Angle-bracket form:

1. Along the path that's specified by each /I compiler option.
2. When compiling occurs on the command line, along the paths that are specified by the INCLUDE environment variable.

GCC

#include <file>

This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the I option (see Invoking GCC in Using the GNU Compiler Collection).

#include "file"

This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories, then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option.

[mwichmann]

It's possible the SConsCPPConditionalScanner addresses this. It has the following in its find_include_file method:

        if quote == '"':                             
            paths = (self.current_file.dir,) + paths

which the default CPP scanner doesn't have.