<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>To test <i>blocks</i>, 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:</div><div>- 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.</div><div><br></div><div>For some tests I really need a 32-bit only system, I need to test against older releases of the OS, etc.</div><div><br></div><div>Its screaming for a BuildBotFarm.</div><div><br></div><div>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?</div><div><br></div><div>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. :-)</div><div><br></div><div>Blaine</div><div><br><div><div>On Mar 7, 2010, at 2:10 PM, James Widman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Mar 7, 2010, at 1:53 PM, Douglas Gregor wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Sent from my iPhone<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Mar 3, 2010, at 8:20 PM, James Widman <<a href="mailto:widman@gimpel.com">widman@gimpel.com</a>> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Mar 3, 2010, at 7:05 PM, Douglas Gregor wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Mar 3, 2010, at 2:44 PM, James Widman wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi all,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm interested in implementing a feature in Clang. The basic idea is that, given a new command-line switch, like perhaps:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--disclose-config<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">... 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.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I assume we would also need the reverse operation, taking a disclosure file and setting Clang's internal options to match the configuration described?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">My motives were so self-serving that this did not occur to me. (:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I assumed that the driver of a 3rd-party tool would have its own disclosure-file-parser and set things up appropriately.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But for completeness, direct support for it in Clang would seem to make sense.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes. I'd hang it off CompilerInvocation, which incapsulates a... Compiler invocation.<br></blockquote><br>Makes sense.<br><br>[...]<br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- Environment variables;<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">How would these affect translation ???<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The environment is harder to control, which is unfortunate. I wonder if all of the environment variables have corresponding flags?<br></blockquote><br>Huh? On POSIX, just use the global variable:<br><br> extern char **environ;<br><br>I think on Windows it's spelled '_environ'.<br><br>In either case, each array element points to a string of the form:<br><br> name=value<br><br>... 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).<br><br>Or for simplicity we just clobber, and if someone really needs "merge" for some purpose they can do it on their own.<br><br>Did I miss something?<br><br>James Widman <br>-- <br>Gimpel Software <br><a href="http://gimpel.com">http://gimpel.com</a><br><br><br><br><br>_______________________________________________<br>cfe-dev mailing list<br>cfe-dev@cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></div></blockquote></div><br></div></body></html>