[PATCH] Implement a sane plugin API for clang

[Sean Silva]

On Fri, Mar 15, 2013 at 9:03 PM, Thompson, John <
John_Thompson at playstation.sony.com> wrote:

>  Hi Sean,****
>
> ** **
>
> I missed the discussion, but I saw your message and wanted to find out
> where things stood on the plug-in API with respect to Windows.
>

I'm probably not the most informed about windows things, but I don't recall
seeing any movement on this front, unfortunately.


> ****
>
> ** **
>
> A year or two ago I wrote a plug-in for Clang for generating LUA bindings,
> and developing on Windows, found that the plug-in mechanism didn’t work on
> Windows, because it relies on how *nix systems do DLLs.  Unfortunately, in
> Windows land, a plug-in DLL would have to be linked with Clang libraries
> which are DLLs, and apparently building the Clang libraries as DLLs is
> problematic, due to the build system and the messy business of
> importing/exporting symbols.****
>
> ** **
>
> I managed to skirt the issue by still building the plug-in against the
> static libraries, and hacking clang to look up call an entry point function
> with a name based on the plug-in name so it could hook up the objects in
> the plug-in.  This, of course, was kind of dangerous, because the plugin
> module and the clang executable would have totally separate static data
> areas, not to mention the duplicated code segments.****
>
> ** **
>
> Then I did some work on making a big Clang DLL, to skirt some of the DLL
> import/export issues, just exporting the symbol references needed between
> the driver and the library, using some header conventions for handling the
> exports.  I intended to pursue this further, and try to resolve the clang
> DLL build issues, but haven’t been able to get back to it.
>

Ouch, that's quite an adventure!

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130316/f9c5a82a/attachment.html>