[cfe-dev] Feature proposal: Compile Configuration Disclosure

[James Widman]

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