[cfe-dev] RFC: Clang driver redesign

[Douglas Gregor]

On Nov 8, 2011, at 12:15 AM, Andrew Trick wrote:

> On Nov 7, 2011, at 8:02 AM, Douglas Gregor wrote:
>>> 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 [*].
> 
> This isn't completely true. gcc is the standard for building *open
> source packages* across platforms, which has only become important
> recently.

I have no idea what you mean by "recently", because open-source code is the #1 priority for Clang, and always has been. Vendors have other means of moving their users to Clang, but Clang only wins mind-share in the open-source world by being compatible (to lower the barrier to entry) and being better (to convince people to stay).

> Your conclusion is correct that tweaking Makefiles cannot be
> a requirement for adopting clang. But the assumption that most users
> are gcc option gurus is wrong, and clang suffers from that mentality.

I have no sympathy for the GCC option gurus. They'll be unhappy anyway, because we're going to accept and ignore all of the codegen-tweaking options they like to play with anyway. But, they don't really matter. 

I do have sympathy for the people who accepted patches from the GCC option gurus, and now have makefiles with weird options they don't understand. Drop-in compatibility with GCC command-line syntax is important to get them 

> The majority of users, build maintainers, need some superficial level
> of compatibility. As long as the build doesn't break, they're happy.

Agreed.

> Moving to a driver that compartmentalizes gcc compatibility would be
> fantastic.

I agree.

> We could finally focus on providing a sensible command-line
> interface for the clang community.

Users won't care; they're best served by just providing GCC compatibility. It could certainly be helpful for us as Clang/LLVM developers, and perhaps for vendors who want to vend a different command-line interface.

> I'm not necessarily advocating two
> drivers so much as a clear and formal segregation between
> first-class clang options and gcc compatibility options.


> This is sort of
> the intent behind the unfortunate "-cc1" and "-mllvm" flags. But they
> only add considerable confusion from my point of view.

-cc1 is historical cruft; it could and should be replaced by something more sane. 

	- Doug