[PATCH] D109192: [WIP/DNM] Support: introduce public API annotation support

[Saleem Abdulrasool via Phabricator via llvm-commits]

compnerd added a comment.

In D109192#2983824 <https://reviews.llvm.org/D109192#2983824>, @MaskRay wrote:

>> I think that `BUILD_SHARED_LIBS` is desirable, and `LLVM_ENABLE_DYLIB` should go away.  That said, I think that the ideal thing here is to have a different configuration that is less granular than `BUILD_SHARED_LIBS`.  That would correspond to `LLVMTools`, `LLVMCompiler` and depending on the delta, a potential third library.  These three would give us a nice hybrid approach to dynamic and static linking.  It would be dynamic for buckets of use (bintuils, clang, and possibly lld if it makes `LLVMTools` too large) but statically linking large components of LLVM to enable us to take advantage of LTO and DCE amongst that set.  It would try to minimise the cost of the GOT/PLT and IAT so that we don't introduce an extremely heavy penalty for these libraries.
>
> Why should `LLVM_ENABLE_DYLIB` go away? To reduce the number of configurations when the few-dylibs scheme is adopted more?
> Other than that, I don't see any downside.

Because the LLVM build system is far too complex.  Once we have the annotations, I don't see why we should continue to use custom build system logic versus the CMake standard `BUILD_SHARED_LIBS`.  That would allow the few dylib scheme to be adopted and reduce the complexity in the build system and homogenise the distribution and development builds hopefully.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109192/new/

https://reviews.llvm.org/D109192