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

Sat Sep 4 14:20:46 PDT 2021

jrtc27 added a comment.

In D109192#2983869 <https://reviews.llvm.org/D109192#2983869>, @compnerd wrote:

> 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.

The whole point of the option though is to make incremental builds faster which is really helpful for development. I'd be against removing that as all my development builds use it.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109192