winksaville added a comment. Just to be clear, I have nothing to do with any distribution except as a user (Arch Linux) so please take what I say and request with a huge grain of salt. As mentioned I have filed a bug <https://bugs.archlinux.org/task 62624> against the clang package in Arch Linux so hopefully we'll be able to get them going in the right direction.
I do have another use case that I've done a little work on. For Pony <https://www.ponylang.io/> they have a problem tracking the various versions of LLVM that distros use so I created a git submodule <https://github.com/ponylang/ponyc/pull/3122> which allows a ponyc developer to work with multiple versions or variations of LLVM simultaneously and switch between them relatively easily. Also, they will eventually switch to bundling libLLVM instead of using the system installed version which could be any version. I have a standalone version of that at mkllvm-tool-chain <https://github.com/winksaville/mkllvm-tool-chain>. Anyway, I'm obviously using "intall" style and I suggest having a `BUILD_CLANG_DYLIB` and `LINK_CLANG_DYLIB` would be useful to more precisely control how a compiler might use the `libclang*`. Some users of LLVM might have a bunch of tools that use various subparts of clang and they might be resident all the time. So startup performance isn't a problem, but reducing the in memory foot print using shared libraries could be useful. Or not building the them at all if they are not using them in anyway. So you're probably correct that for distros these flags shouldn't be used, but for other use cases of LLVM I think there are. In anycase, I think this is a worth while change as it and If you're still not convinced I like to see this in sooner rather than later. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61909/new/ https://reviews.llvm.org/D61909 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits