[cfe-dev] [cfe-commits] Design proposal: Add custom compilation database formats as plugins

Michael Spencer bigcheesegs at gmail.com
Wed Jul 18 13:02:31 PDT 2012


On Wed, Jul 18, 2012 at 11:51 AM, Manuel Klimek <klimek at google.com> wrote:
> On Wed, Jul 18, 2012 at 8:08 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>
>> On Jul 18, 2012, at 6:36 AM, Daniel Jasper <djasper at google.com> wrote:
>>
>>> Hi all,
>>>
>>> to make the tooling library more widely applicable, we'd like to make the CompilationDatabase architecture extensible, i.e. provide the option of implementing custom adapters to other kinds of compilation databases (other than the currently available JSONCompilationDatabase).
>>>
>>> In r160061, I provided a hack that enables this, but we definitely want something nicer.
>>>
>>> In the attached patch, I am using LLVM's plugin registry to enable registering new compilation databases. To provide a new CompilationDatabase, you'd need to subclass CompilationDatabasePlugin and CompilationDatabase and register the former with CompilationDatabasePluginRegistry::Add (as shown for JSONCompilationDatabase). This is not a finished patch for review, I'd just like to get feedback on the approach. What do you think?
>>
>> I definitely prefer this approach!
>
> My main argument against static registries is (bad) experience with
> using them in Windows / DLL environments. Looping in Michael Spencer
> to verify that this will not be a problem here (I really want the
> tooling stuff to not run into problems with Windows down the line).
>
> Cheers,
> /Manuel

This will work if statically linked, but not dynamically unless the
__declspec(dll{export,import}) stuff is sprinkled on. However in this
case it may be possible as the interface seems quite small. Although
it would also require adding sprinkles to any non-stdlib c++ types
that are passed through the interface.

- Michael Spencer

>>> Also, several points that need to be addressed:
>>> - Error handling: In CompilationDatabase::loadFromDirectory, I currently simply try each plugin until I find a compilation database. Any ideas, what I should do with the error messages, especially if I do not find any compilation database. Should I concatenate them, potentially with the plugin-name as a prefix?
>>
>> Yes, I think it's reasonable to concatenate them with the name of the plug-in, because we don't know which plug-in the user intended to use.
>>
>>> - Should I move the JSONCompilationDatabase to a separate set of files as it is now loosely coupled?
>>
>> Sure!
>>
>>         - Doug
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits




More information about the cfe-dev mailing list