On Wed, Jul 18, 2012 at 11:51 AM, Manuel Klimek <[email protected]> wrote:
> On Wed, Jul 18, 2012 at 8:08 PM, Douglas Gregor <[email protected]> wrote:
>>
>> On Jul 18, 2012, at 6:36 AM, Daniel Jasper <[email protected]> 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
>> [email protected]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
