[llvm-dev] [Windows Installer] Headerless install package?

[Jack Andersen via llvm-dev]

Thank you Hans,

Thought the CRT had something to do with it.

I've also discovered that mixing release/debug libraries is a major no-no for the MSVC linker. 

I sorta figured Windows would pose many challenges for a modular project, though now I can properly explain that to my users. 

> On Oct 12, 2015, at 11:33, Hans Wennborg <hans at chromium.org> wrote:
> 
> Hi Jack,
> 
> 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
> down.
> 
> 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
> the installer.
> 
> Cheers,
> Hans