Splitting up llvm as a compiler and llvm as a library

[chuckatkins]

It's possible this has been already discussed and I may have missed it, so my apologies if that's the case.

I am very happy to see the llvm-based *lang compilers as an option now. However, as more codes in the HPC space are beginning to utilize llvm as a library, it would be helpful to separate the compilers as libraries to allow for libllvm to be made available with other compilers. Packaging wise, I think this could look something like this:

• llvm5-compilers-ohpc
  • The LLVM compilers and std libs (clang, clang++, flag, llvm-ar, llvm-ld, etc.) but no actual llvm libraries. (maybe build with llvm libs statically linked into the tools)?
• libllvm5-{gnu,gnu7,intel,llvm5}-ohpc
  • LLVM libraries that can be linked to by applications built with the associated compilers.

This would allow for things like module load intel libllvm5 to build something with the Intel compiler that uses LLVM as a library, also built by the Intel compiler.

[koomie]

I brought this up in today's TSC meeting and it was generally well received. I would not go for static linkage but think we can separate as you suggest and will queue for future work. Thanks for the suggestion.

[chuckatkins]

The suggestion of static linkage into the compilers is to avoid the circular dependency between llvm compilers and libllvm and allow the llvm compilers to be loaded by themselves. I made the suggestion because I know the clang/llvm build supports it for this very reason. I'm not particularly tied to the static linkage though. I'm mostly wanting to have an llvm library module I can load with the Intel compiler.

Thanks for taking a look!