[llvm-dev] [Windows Installer] Headerless install package?
Hans Wennborg via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 12 14:33:50 PDT 2015
On Sun, Oct 11, 2015 at 3:34 PM, Jack Andersen via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I've authored a tool based on clang's libtooling and wish to make its build process similar to LLVM's via cmake on multiple platforms.
> I'm primarily developing on Arch Linux (with the distribution-provided llvm) and also maintain OS X builds using the prebuilt library archive from llvm.org. The llvm packages for these platforms contain exactly what I expect: /lib, /include, /bin, /share/cmake directories of everything from a default LLVM build configuration.
> When I shift my attention to Windows (building with VS) I'm unable to build my tool with the official NSIS package of LLVM for two reasons:
> - include exists, but only with (incomplete) C headers, no C++ headers at all
> - no cmake package/modules whatsoever
> Seemingly, the only use for the official NSIS package is the clang driver and any tools that dynamically load the llvm/clang .dlls
> I find this Windows deficiency rather odd, since the OS X package is complete for tool developers. I've worked around this issue by building llvm/clang on Windows myself and running CPack to produce a complete NSIS package (weighing in at ~77MB).
> Is there a motivation behind the stripping of this package against tool developers? I'd like users to clone my tool source and build it quickly without building llvm in its entirety.
The Windows installer (both the stable releases and weekly snapshots)
is targeted towards developers who wish to use Clang as a toolchain,
not as a library. The idea from the start was to optimize for early
adopters who wanted to try out clang-cl. The headers and libraries
aren't necessary for that, so we excluded them to keep binary size
Besides the binary size issue, shipping the libraries in a useful way
is also tricky. We'd have to choose which msvcrt version to link with;
ideally it should match the one used by the library consumer.
This probably doesn't help you much, but that's the reasoning behind
More information about the llvm-dev