beanz added a comment. In D61909#1502446 <https://reviews.llvm.org/D61909#1502446>, @winksaville wrote:
> Questions: > > - Should we only build `libclang_shared.so` if `LLVM_BUILD_LLVM_DYLIB` is ON? `LLVM_BUILD_LLVM_DYLIB` is actually not the important option to think about because it has no impact on this, rather `LLVM_LINK_LLVM_DYLIB`. That really depends on what tradeoffs you want. With that option off LLVM will be linked statically into the Clang library, which in the common case is fine because you can resolve all the LLVM & Clang APIs against it. That will be faster to load, but a larger binary distribution. With the option on, libclang_shared will link libLLVM, which will result in slower loading times, but smaller distributions. Both are workable situations. > - Should we use link clang-9 to libclang_shared.so when > `LLVM_LINK_LLVM_DYLIB` is ON? No. If we want to support that it should be through its own option which we can add in a subsequent patch. > - Or maybe we should define `BUILD_CLANG_DYLIB` and `LINK_CLANG_DYLIB` or ... > ? I'm not sure there is value in a `BUILD_CLANG_DYLIB` option (and frankly `LLVM_BUILD_LLVM_DYLIB` should probably go too). Between when I added the support for building libLLVM and now I've shifted my mindset about build system functionality. Optimizing the build time of the `all` target seems way less worthwhile to me than reducing complication in the build system. Most developers iterate by running `check*` targets over and over again rather than building `all`, and as long as the dependencies are properly set up adding additional targets has little impact on iteration time or perceived build time. A `CLANG_LINK_CLANG_DYLIB` option probably does make sense to add in order to support smaller binary distributions, although I am concerned about communicating the impact of that and the `LLVM_LINK_LLVM_DYLIB` options. In the past I've seen people do compile-time performance comparisons between GCC and Clang using the `BUILD_SHARED_LIBS` option when building Clang, and it leads to really misleading results. I would be very frustrated to see a pile of blog posts saying that Clang is getting slower just because people are deciding to make clang dynamically link its components. 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
