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

[James Molloy]

Hi,

Thanks for all the replies. I've kind of summarised the main points of
contest so far below and tried to group supporters and opponents. If
I've grouped you incorrectly, please don't take it slanderously :)

I've distilled the conversation so far into:
  * Accepted command line options should be easy to change, add and
    remove. Invoke time vs build time? Not decided.
  * Most options should be able to be modified at invoke time.

There have been discussions about invoke-time vs. build-time in terms of
specifying the driver behaviour - Can we discuss that a bit more?

Many people want to have a configuration file that can do almost
everything at invoke-time, but to cover all use cases that would
require turing completeness and a full-on scripting language, which
has been pooh-poohed already (and I don't agree with anyway).

My original suggestion was separating out "behavioural adaptation" and
"platform configuration" into different buckets. 

"behavioural adaptation" could include the GCC compatibility story,
adding extra command line flags, exposing internal functionality etc.

"platform configuration" could include setting up a cross-toolchain,
multilib, include files, and even at a push changing the subtool to
invoke (for producing non-llvm output).

I'd suggest that behaviour changes should be done in C++ as it is
turing complete, fast, has precedent and these changes should in
general not differ between platforms or users.

Platform configuration can be done by a configuration file / spec
file, and because it is just setting parameters or options this can be
relatively simple, just variable assignment and string
manipulation/interpolation.

****

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

More command line options
=========================

+Matthew Monrocq, Ruben Van Boxem, Hal Finkel
-Eric Christopher

There were questions as to whether we should allow access to compiler
internal features or not. My personal opinion is that internal options
should be exposed both for power users and for remote debugging /
working around compiler errata before a patch is available.

Regardless, this ties in with the GCC question in that the option
should be there, should we choose to use it policy-wise.

Plugins producing non-llvm output
Driving extra optimizations
=================================

+David Chisnall

Excellent use cases that tie in well with what I have already. I'll
add them to the document.

Cross compile toolchain
=======================

+David Chisnall, Jean-Daniel Dupas

This is the exact same use case that we see here that is certainly not
covered by the current driver.