[cfe-dev] Tests and include paths

[John Thompson]

Here's a patch for using environment variables to set up default
include paths for Visual Studio.

I know it's not optimal yet, but I think it's an improvement over just
hard-coding paths.

I still put in some hard-coded paths if the environment variables are
not found.  It seems that when run under the Python test scripts, the
environment is lost.  Does anyone know anything about this?  Is it
possible to tell Python to pass through the environment?

-John

On Wed, Aug 12, 2009 at 5:34 PM, Daniel Dunbar<daniel at zuster.org> wrote:
> Hi John,
>
> These are my opinions:
>
> 1. WIth regard to the first problem, this is a configuration problem
> (or perhaps an autodetection problem). The compiler should not have
> the giant union of all possible include paths, it should be configured
> for the include paths that match the system. For now since we do have
> the giant union, I have no problem adding some more standard MSVC
> paths.
>
> 2. I think using standard headers in tests is fine. After all, users
> of a C compiler probably want #include <stdlib.h> to work, for
> example.
>
>  - Daniel
>
> On Wed, Aug 12, 2009 at 12:26 PM, John
> Thompson<john.thompson.jtsoftware at gmail.com> wrote:
>> 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:
>>
>> C:\\cygwin\\usr\\include
>>
>> 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.
>>
>> -John
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32_include_paths.patch
Type: application/octet-stream
Size: 2390 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090813/525d8dcc/attachment.obj>