[PATCH] Implement a sane plugin API for clang

[Thompson, John]

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.

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.

Has anyone else worked on resolving the plugin issues for Windows or the Clang-libraries-as-DLLs build?

-John

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