[cfe-dev] RFC: Clang driver redesign

[Douglas Gregor]

On Nov 4, 2011, at 7:55 AM, Sean Hunt wrote:

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


GCC compatibility is and has always been crucial to the viability of Clang, *especially* in the driver, which needs to deal with many years of accumulated cruft in makefiles and command lines. Unlike with language compatibility, where we can differ from GCC to better adhere to a language standard, GCC's driver *is* the standard for most *nix systems out there. You won't win the hearts and minds of users if you tell them to change all of their makefiles before they can even try Clang.

By all means, please make it easier to build and distribute cross compilers, but any Clang driver that does not provide GCC compatibility is likely to be a non-starter [*].

	- Doug

[*] The natural exception would be a driver designed for compatibility with a different compiler, e.g., a Clang that accepts Microsoft CL command-like syntax.