[cfe-dev] Feature proposal: Compile Configuration Disclosure

[Blaine Garst]

I have some similar interests, perhaps we should talk offline.  Send me your phone (privately!) and I'll give you a call if you want.

To test blocks, for example, I have a little hacked up tool that can build and test source language level tests; for each test the tool currently can:
- compile a test using any of the {C, ObjC, C++, ObjC++} compiler variants as {32,64} bit binaries, using {-c99, {-fobjc-gc, -fobjc-gc-only, no-gc}, -O{1,2,3}} as basic configurations, and then test that the variation either {expectedCompileFailWithMessage, expectedWarningWithMessage, expectedCleanCompile} and if so then tests {expectedRunFatal, expectedRunClean, expectedRunWithWarning}... etc.

For some tests I really need a 32-bit only system, I need to test against older releases of the OS, etc.

Its screaming for a BuildBotFarm.

As part of that, I will refine my existing configuration schema system so that it can drive clang from the outside, as in, here's a spec, fork/exec/monter clang with the options.  I would love to drive it from the inside as well for other purposes, so I would love to discuss how to specify the "Configuration Space".  The LLVM/Clang OptionParser stuff is really cool, the goal would be to produce an option config from the spec that is equal to the command line, right?

I'm currently a fan of YAML as an portable representation format, but there is a tiny little configuration language that would drive into/outof the representation.  Enough said.  :-)

Blaine

On Mar 7, 2010, at 2:10 PM, James Widman wrote:

> 
> On Mar 7, 2010, at 1:53 PM, Douglas Gregor wrote:
> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Mar 3, 2010, at 8:20 PM, James Widman <widman at gimpel.com> wrote:
>> 
>>> 
>>> On Mar 3, 2010, at 7:05 PM, Douglas Gregor wrote:
>>> 
>>>> 
>>>> On Mar 3, 2010, at 2:44 PM, James Widman wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I'm interested in implementing a feature in Clang.  The basic idea is that, given a new command-line switch, like perhaps:
>>>>> --disclose-config
>>>>> ...  Clang would output, to a plain text file (which I'll call a "disclosure file"), information about the compilation environment sufficient for a third-party program to observe the same sequence of tokens that Clang saw.
>>>>> 
>>>>> So basically, providing this dump enables one to perfectly emulate not just the compiler but a *specific run* of the compiler.  Note that tools based on Clang libraries could make use of information in disclosure files.
>>>> 
>>>> I assume we would also need the reverse operation, taking a disclosure file and setting Clang's internal options to match the configuration described?
>>> 
>>> My motives were so self-serving that this did not occur to me.  (:
>>> 
>>> I assumed that the driver of a 3rd-party tool would have its own disclosure-file-parser and set things up appropriately.
>>> 
>>> But for completeness, direct support for it in Clang would seem to make sense.
>> 
>> Yes. I'd hang it off CompilerInvocation, which incapsulates a... Compiler invocation.
> 
> Makes sense.
> 
> [...]
>>>>> - Environment variables;
>>>> 
>>>> How would these affect translation ???
>>> 
>>> Well, some compilers depend on environment variables.  E.g. MSVC uses the variable INCLUDE, which names directories containing headers that ship with the compiler.  And GCC uses several environment variables; see the section 'ENVIRONMENT' in the GCC manual.
>>> 
>>> Granted, INCLUDE would already be covered in the second bullet point above.  But it's always possible that the environment will contain something that alters a compiler's behavior in some unexpected way.
>> 
>> The environment is harder to control, which is unfortunate. I wonder if all of the environment variables have corresponding flags?
> 
> Huh?  On POSIX, just use the global variable:
> 
>  extern char **environ;
> 
> I think on Windows it's spelled '_environ'.
> 
> In either case, each array element points to a string of the form:
> 
>  name=value
> 
> ... where 'name' does not contain '='.  When serializing, we simply dump that out (into an XML element).  When de-serializing, I guess there might be an option between a "merge" vs. "clobber": in merge, you simply do setenv() for each of the definitions given in the config-disclosure file; in clobber, you first unsetenv(name) (for each name in environ that is not in the disclosure file) and then you setenv(name,value,1) (for each name/value pair from the config-disclosure file).
> 
> Or for simplicity we just clobber, and if someone really needs "merge" for some purpose they can do it on their own.
> 
> Did I miss something?
> 
> James Widman  
> -- 
> Gimpel Software 
> http://gimpel.com
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100308/573e87af/attachment.html>