[PATCH] D109192: [WIP/DNM] Support: introduce public API annotation support
Jessica Clarke via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Sep 5 12:18:47 PDT 2021
jrtc27 added a comment.
In D109192#2984255 <https://reviews.llvm.org/D109192#2984255>, @compnerd wrote:
> In D109192#2984252 <https://reviews.llvm.org/D109192#2984252>, @jrtc27 wrote:
>
>> In D109192#2984249 <https://reviews.llvm.org/D109192#2984249>, @compnerd wrote:
>>
>>> I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.
>>
>> We have significant downstream changes, and we regularly build with shared libraries for development, only static linking in our release builds. This will affect us and having to chase down a bunch of functions with LLVM_SUPPORT_ABI does not fill me with joy. Yes, static linking is great for releases, but it sucks for development, full per-component shared libraries make things much faster, please don't just dismiss it.
>
> Well, per-component would be significantly worse - `LLVM_SUPPORT_ABI` marks what just `LLVMSupport` exports. You would need a separate macro per component if you do a shared library build with a per-component shared library. Doing a set 2-3 libraries means that there are only 2-3 macros that need to be contended with and its easier to identify which module the function resides in. That also means that it is more viable to find LTO/DCE optimizations.
I don't care about efficiency downstream, I just don't want it to be broken. If you break per-component shared libraries you force me to change my workflow and have slower incremental builds. If I have to go chasing down build errors because our additions need exporting in order for the monolithic shared build to work then I get grumpy at the busywork. If there's strong technical justification for the latter, fine, but please do it in as least disruptive a way as possible (i.e. with as much automation as possible, and in one go rather than spread across 10s of commits). I see no technical justification for the former, that would just be breaking workflows that you personally don't use.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109192/new/
https://reviews.llvm.org/D109192
More information about the llvm-commits
mailing list