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!
> 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
