Some of the tests have #includes which can be problematic across platforms.
Part of the difficulty is in how the default include paths are done now.
Setting C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJCPLUS_INCLUDE_PATH, and OBJC_INCLUDE_PATH to the host compiler’s includes directory allows the compiler to find the include files, except that in running the tests with the Python script, the environment variable doesn’t seem to be getting through. It did seem to work while running the compiter under the debugger or directly from the command line, however.
The InitHeaderSearch.cpp file sets up a hard-coded path for VS9 on a g: drive, which of course, is not likely to match most users. Perhaps also adding:
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE
C:\Program Files\Microsoft Visual Studio 8\VC\include
might match most users, since these are the default installation paths. And while we’re at it, throw in Cywin’s path:
I can give you a patch for this, if you want. After adding this, the failed test count went from 230 to 204.
Or, it wouldn’t be too hard to use the environment variables VS80COMNTOOLS and VS90COMNTOOLS to look for them, or perhaps something from the registry. Shall I try this and submit a patch for this instead?
However, a key issue I want to get to in this posting is that the compiler might not be ready for everything in the host compiler’s includes, specifically both Visual Studio and Cygwin in this case, as unexpected messages arising from compiling these files are making some tests fail.
My question is, do we really want to #include standard headers in the tests?
Or, if we need certain definitions from them, should we perhaps create a set of canonical headers with just the definitions needed for the tests and include those instead, changing the #include’s in the tests to be relative, to make it obvious?
Or, what other solutions might there be? Because of licensing, I’m guessing you couldn’t just check-in some GNU headers from a platform deemed the reference standard.