<br><br><div class="gmail_quote">Le 8 novembre 2011 13:08, David Chisnall <span dir="ltr"><<a href="mailto:csdavec@swan.ac.uk">csdavec@swan.ac.uk</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 8 Nov 2011, at 11:23, James Molloy wrote:<br>
<br>
> "To GCC or not to GCC, that is the question"<br>
> ============================================<br>
><br>
> +Doug Gregor, Miles Bader<br>
> -Sean Hunt, Christopher Jefferson, Andrew Trick<br>
><br>
> There is differing opinion on the amount of GCC compatability clang<br>
> should offer. A lot of examples and arguments have been given, but I<br>
> see one conclusion - the driver should not be pinned to anything.<br>
><br>
> Depending on policy decisions, the user interface should be able to be<br>
> changed with minimal effort.<br>
<br>
</div>GCC compatibility is definitely an advantage, but if the driver infrastructure is tidied up then it becomes a lot easier to add new GCC-incompatible drivers as well.  I think a lot of people would like to see a cl.exe-compatible one that can just be dropped into MSVC, and it might also be useful to provide a driver that had a less human-friendly set of options that is easier for an IDE to invoke (e.g. no defaults, everything explicitly configured and driven by the IDE's build description).<br>

<br>
One other use case I forgot to mention: Objective-C runtime selection.  This is easy on Darwin, because Apple ships an Objective-C runtime and supports it for the duration of that release.  It's much harder on other platforms, where the runtime is a third party package and may support some variable subset of the features that clang supports.  The driver currently sets a load of codegen flags based on the runtime on Darwin, and it would be great if we could have runtimes on other platforms just drop in a config file that clang would automatically pick up and use to describe them.  This would also make my life easier when I add new features to the GNUstep runtime, as I could just flip a switch in the config file and have clang use them, rather than having to rely on users adding yet more flags to their make files...<br>

<br>
David<br>
<br>
-- Sent from my Apple II<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>I fully support this idea!<br><br>I think we would all benefit from a tidier architecture where we could have:<br>
> a clang driver: which gives us the opportunity to cleanly define 
option groups (whatever the policy, it can only be cleaner than gcc)<br>> a gcc compatible driver: in which we struggle to maintain the compatibility with gcc interface as much as possible<br>> possibly other special purpose drivers (MSVC is definitely one option, seeing as there is ongoing work to get MSVC compatible codegen and a Windows enabled libc++)<br>
<br>Note for compatibility drivers (gcc, MSVC): it's unnecessary to bring new options here, as the purpose is to provide a compatible interface (drop-in replacement) not an actual improved one. Also, if we have the translation going, we might as well generate a small tool that takes a "compatible" command-line and spits out the equivalent clang command line.<br>
<br>And this "multi-entry points" approach actually allow us to contend with the presence of a configuration file as well: want to use a configuration file ? Invoke the "configuration-file" driver.<br>
(Although honestly, we could perfectly provide the configuration file thing as a variety of scripts parsing the file and generating the suitable command line)<br><br>If we have a clean Driver design, then adding several flavors of options parsing should be easy. Of course we would still need be reasonable and not spew dozens of them...<br>
<br>-- Matthieu<br><br> <br></div></div><br>