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

[Daniel Jasper]

Cool, so I'll go ahead and finish this patch. There is one remaining issue:
If I don't use anything from a .o file, the linker will simply disregard
it, thereby rendering the contained compilation database useless. Is there
a standard way to prevent that?


On Wed, Jul 18, 2012 at 10:13 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Jul 18, 2012, at 1:02 PM, Michael Spencer <bigcheesegs at gmail.com>
> wrote:
>
> > 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.
>
> Being limited to static linking on Windows seems fine for now; it's what
> Daniel's prior solution was doing already, and we know roughly what we need
> to do to get dynamic linking working better on Windows.
>
>         - Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120718/f3c4e876/attachment.html>