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?<div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jul 18, 2012 at 10:13 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Jul 18, 2012, at 1:02 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>> wrote:<br>
<br>
> On Wed, Jul 18, 2012 at 11:51 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
>> On Wed, Jul 18, 2012 at 8:08 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br>
>>><br>
>>> On Jul 18, 2012, at 6:36 AM, Daniel Jasper <<a href="mailto:djasper@google.com">djasper@google.com</a>> wrote:<br>
>>><br>
>>>> Hi all,<br>
>>>><br>
>>>> 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).<br>

>>>><br>
>>>> In r160061, I provided a hack that enables this, but we definitely want something nicer.<br>
>>>><br>
>>>> 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?<br>

>>><br>
>>> I definitely prefer this approach!<br>
>><br>
>> My main argument against static registries is (bad) experience with<br>
>> using them in Windows / DLL environments. Looping in Michael Spencer<br>
>> to verify that this will not be a problem here (I really want the<br>
>> tooling stuff to not run into problems with Windows down the line).<br>
>><br>
>> Cheers,<br>
>> /Manuel<br>
><br>
> This will work if statically linked, but not dynamically unless the<br>
> __declspec(dll{export,import}) stuff is sprinkled on. However in this<br>
> case it may be possible as the interface seems quite small. Although<br>
> it would also require adding sprinkles to any non-stdlib c++ types<br>
> that are passed through the interface.<br>
<br>
</div>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.<br>

<br>
        - Doug<br>
</blockquote></div><br></div>