[PATCH] D75579: [WIP] Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by libraries

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D75579#1912535 <https://reviews.llvm.org/D75579#1912535>, @serge-sans-paille wrote:

> @MaskRay The library version prooved to be a bad path: we wanted clang-cpp to always link to a shared library, which interacts in ungraceful ways with BUILD_SHARED_LIBS.
>
> This is another attempt that looks better to me: all options are available in LLVMCodeGen, but only registered if a given static constructor is called by client code. Some doc and asserts are missing but that's the rough idea. Any thoughts?


I think the patch is moving toward the correct direction and fixes some problems, so there is still value to land it. Placing static constructors in a header which may be included in two places in an application (application codegen; lld depended by the application) is bad. With this patch, at least the `-DBUILD_SHARED_LIBS=off` build (`libLLVM*.a`) will work now.

(A `-DBUILD_SHARED_LIBS=on` build will also work. In this case, the application should link against `libLLVM*.so` and `libclang*.so`, but no distribution has done this. The application will have to link against a number of `libclang*.so`, instead of a single `libclang-cpp.so`)

A copy of `libLLVMCoreGen.a` is linked into `libclang-cpp.so`. If the application depends on `libclang-cpp.so`, it cannot pull in another `libLLVMCodeGen.a`, because that will cause duplicate registration of `llvm::cl::opt` flags.
I agree that we have to let client code explicitly initialize (register) the flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75579