beanz added a comment. In D66068#1636240 <https://reviews.llvm.org/D66068#1636240>, @jvesely wrote:
> sorry for the delay. I fully understand the need to reduce the number of > options. Having always used SHARED_LIBS build I remember weekly shared build > breakages. This is exactly what we want to avoid in the future by simplifying build configurations. > That said, forcing everyone to build one huge library effectively makes debug > builds unusable in any practical way. Nobody is forced to build this. You can run the `check` targets which don't include this library in their dependency chain, and you can use the `LLVM_DISTRIBUITON_COMPONENTS` option I mentioned earlier to create build and install targets that exclude it. We are just including it as part of the `all` target, because it is part of building everything. Where I think you and I are really disagreeing is that you seem resistant to altering your workflow. > What is the use-case of one big shared lib that split libraries can't do? clang-cpp is an installable and shippable library, which is not the use case that the split libraries were designed for. Also, since it is a shared library, tools can be linked against it to reduce binary distribution sizes (at the cost of some runtime performance). It is worth noting that the `BUILD_SHARED_LIBS` option is explicitly documented in several places as being for developer use only, not for shipping. Which means this is the only supported mechanism for shipping clang's logic in a shared library. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66068/new/ https://reviews.llvm.org/D66068 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
