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

Reply via email to