I’ve updated my experimental Clang big DLL patches, against revision 138276 (8/22/11).
To recap, this creates a big Clang DLL, and links key executables against it. This is needed to allow plug-ins and other DLL-dependent applications to share the Clang code and static data on Windows (i.e. it fixes the plug-in registry mechanism which doesn’t currently work on Windows).
To preserve the present build hierarchy I did some stuff under the covers in the cmake stuff to allow a new ClangDLL project to reference all the sources from the Clang and LLVM libraries, and redirect the executable builds to link against the clang DLL instead of the static libraries.
Regarding the Clang sources, I added “(name)_LINKAGE” tags to key symbols needed to build the clang executable. These symbols are defined in new per-library-project headers “(name)Common.h”.
Because of their size, I stored the patches externally here:
http://www.jtlanguage.com/xfer/dll_llvm_patch.txt
http://www.jtlanguage.com/xfer/dll_clang_patch.txt
To do the build, delete the CMakeCache.txt file from the LLVM root, and regnerate the Visual Studio project files using:
cmake -G “Visual Studio 10” -DCLANG_BUILD_EXAMPLES=ON -DLLVM_BUILD_DLL=ON .
The “DLLVM_BUILD_DLL” flag enables the DLL build.
For more info, please see my prior postings, mostly entitled “Big Clang DLL, plug-in mechanism revision” (May 4, 2011), or drop me a line.
In particular, I’m hoping Chris can take a look at it, since it’s a significant architectural thing.
Note that I haven’t exported everything that probably needs to be exported, just enough to get the driver and some plug-ins to build and run. I’m thinking we can just add tags as needed. I think there might be a limit on the total number of symbols that can be exported (16k?), so we probably can’t just export everything, which is probably not needed anyway.
While building, you might run into a dependency problem regarding the generated “.inc” files. If so, just run “Build” (not Rebuild) again.
Thanks.
-John