[cfe-dev] RFC: Clang driver redesign

[Sean Hunt]

On Fri, Nov 4, 2011 at 07:11, James Molloy <james.molloy at arm.com> wrote:
> Usecase 3: Clang developer, developing
> --------------------------------------
>
> Wants no functionality to change - things keep working as normal [1]
>
> Usecase 4: Apple/Darwin developer, using fat binaries
> -----------------------------------------------------
>
> Requires fat-binary support. This entails multiple "-arch" arguments
> being supported. [1]
>
> .. note::
>
>    Describe this some more?
>
> Functional requirements
> =======================
>
> The following requirements follow from the use cases above and attempt
> to formalise those use cases more precisely.
>
> [1] No functional regressions
>  The driver **must** be able to be configured such that it can parse
>  command lines that the current Clang driver accepts. The driver
>  **must** invoke all subtools in the same manner as the current Clang
>  driver, with the possible exception of obtuse, undefined, legacy or
>  otherwise incorrect behaviour, permission for which must be obtained
>  from the mailing list and documented in a subsection of this
>  document for decision tracking.

I honestly have to disagree with this one. A lot of the reasons for
horribleness in the current driver is compatibility with GCC. I
believe that we should really have two drivers, one being the 'nice'
driver, and one being the compatibility driver. To be honest, I
consider POSIX specifications for CC rather irrigating as well, but
I'm willing to concede POSIX compatibility. Naturally, it should be
easy for these to both be changeable at once so that we don't have
ridiculous levels of maintenance being performed, but I'm of opinion
that the current model is predicated on enough levels of annoyances
that trying to promote a compatible compiler is not a good approach
(the first example that comes to mind is -Wall).

I'm sure people will disagree with me, though.

> [3] Extensibility
>  All parts of the driver that are to interact with outside
>  environment (such as interpreting command lines and launching
>  subtools) **must** be able to have their behaviour easily modified.
>
>  While there is no requirement for this to be able to be done with no
>  source changes, there **could** be scope for allowing dynamically
>  loadable modules (in the spirit of ``opt -load``) to change the
>  driver's behaviour at invoke-time.

Oh no, spec files. ;)

Sean