[PATCH] D16760: Add support for importing and exporting Registry objects on Windows

[Ehsan Akhgari via llvm-commits]

ehsan added a comment.

In http://reviews.llvm.org/D16760#342227, @rnk wrote:

> In http://reviews.llvm.org/D16760#342060, @ehsan wrote:
>
> > Importing symbols on Windows is a hopeless effort.  We'd either need to spray everything in clang with a CLANG_API macro that resolves to dllimport/dllexport depending on what you're building, or maintain a .def file with mangled names of everything we export, both of which are terrible solutions IMO.  This setup is intended to be used with static linking:
>
>
> CMake has some new auto-export functionality that I want to look into at some point. It didn't work immediately out of the box, so I had to put it aside for now, but eventually, I would like to stop statically linking clang.exe.


Nice!  I didn't know about that.


================
Comment at: include/llvm/Support/Registry.h:172
@@ +171,3 @@
+  REGISTRY_CLASS::import(DL, #REGISTRY_CLASS)
+#endif
+
----------------
rnk wrote:
> ehsan wrote:
> > rnk wrote:
> > > Do you think we should have an #else block here that defines these macros to nothing on Unix, so that clients don't have to do the platform ifdefs?
> > That sounds like a good idea.  (FWIW I'm really unhappy that we needed to change the client side API for this, but sadly there is no way to avoid that.)
> What if we kept the export side (the non-client side) the same and changed the Registry constructor to do dynamic lookup in all loaded DLLs for the exported symbol? Then we'd only have to change clang and opt.
Do you mean the Registry constructor running in the plugin to look at all loaded modules for a `AddNodeToRegistry` function and call that instead of `add_node()` in this patch to add its registrations to the Registry in clang.exe?  (I'm not sure how opt enters the picture here.)


http://reviews.llvm.org/D16760