[cfe-dev] RFC: Clang driver redesign (round 2)

[Matthieu Monrocq]

Le 8 novembre 2011 13:08, David Chisnall <csdavec at swan.ac.uk> a écrit :

> On 8 Nov 2011, at 11:23, James Molloy wrote:
>
> > "To GCC or not to GCC, that is the question"
> > ============================================
> >
> > +Doug Gregor, Miles Bader
> > -Sean Hunt, Christopher Jefferson, Andrew Trick
> >
> > There is differing opinion on the amount of GCC compatability clang
> > should offer. A lot of examples and arguments have been given, but I
> > see one conclusion - the driver should not be pinned to anything.
> >
> > Depending on policy decisions, the user interface should be able to be
> > changed with minimal effort.
>
> 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).
>
> 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...
>
> David
>
> -- Sent from my Apple II
>
>
I fully support this idea!

I think we would all benefit from a tidier architecture where we could have:
> a clang driver: which gives us the opportunity to cleanly define option
groups (whatever the policy, it can only be cleaner than gcc)
> a gcc compatible driver: in which we struggle to maintain the
compatibility with gcc interface as much as possible
> 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++)

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.

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.
(Although honestly, we could perfectly provide the configuration file thing
as a variety of scripts parsing the file and generating the suitable
command line)

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...

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111108/fe7a0157/attachment.html>