[cfe-dev] Getting involved with Clang refactoring

[Douglas Gregor]

On May 24, 2012, at 4:52 AM, Arnaud de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote:

> On 05/24/2012 01:29 PM, Manuel Klimek wrote:
>> 
>> Hi Dave,
>> 
>> thanks for writing all the stuff down!
>> 
>> I don't think that an "official" solution for how to generate the compile database is important, as long as
>> 1. the format is clear
>> 2. we support a wide range of use cases
>> 
>> This is open source :) People can generally implement all of the above solutions. Some of them might not need to live inside clang's repository; it would generally be good to have at least one solution that is as generic as possible living inside clang without the need for 3rd party things (like cmake or ninja). I think for that solution the switch is the best one, as it's the only one that does not increase the dependency needs of clang users at build time.
>> 
>> Thoughts?
>> /Manuel
> 
> Hi Manuel & Dave,
> 
> Although the switch makes it easy to be a self-contained solution, this is not generic enough to cover an important use case : people may not be using clang for compiling their code, but still want all the clang goodies (code completion, ...) thru an external tool. This is for example the case when using clang_complete with vim : you are not forced to compile your project with clang.


As time goes on, I find myself caring less and less about code that isn't compiling with Clang. Abstractly, I care about people being able to use Clang-based tools even if they don't compile with Clang. However, I would much prefer us to spend our time making the Clang ecosystem *awesome*, so that once your code parses/builds with Clang, you get access to a variety of useful tools. The compilation-flag approach to building a compilation database is by far the easiest solution for people to use if they're already building with Clang, and therefore that's the one I'm most interested in.

	- Doug