[llvm] [cmake] Add a new flag MERGE_INTO_LLVM_DYLIB to llvm_add_library (PR #158023)

[Tomohiro Kashiwada via llvm-commits]

kikairoya wrote:

> Is it correct that this is supposed to fix Polly with `-DLLVM_LINK_LLVM_DYLIB=ON` in Windows (#156440), or other problems as well?

Sorry for the lack of context. This PR, together with #156440, is intended only to address #152328.
#115431 seems to aim for a slightly different objective.

> It currently is not clear to me when MERGE_INTO_LLVM_DYLIB should be used. The description uses "foreign project library", but when is a library "foreign"?

I meant that "foreign" is a component (usually a plugin, but not restricted to that) that is linked into libLLVM and placed out of `llvm/` source tree, whether in or out of the monorepo.

> > I really do not like this direction. We already have the proper tools for this in CMake: Object Libraries. We should explicitly create the object library which will effectively "merge" the libraries. All of this custom scaffolding in LLVM makes it harder for newcomers to the project and prevents the use of the existing documentation from being useful.
> 
> I fully agree, this change is adding more complexity making it harder to understand and maintain the LLVM build system. We should be instead looking for opportunities to simplify our build system by leveraging standard CMake mechanisms like object libraries which seems to be the best fit for what you're trying to achieve with this change.

Could you elaborate on what exactly is meant by "Object Libraries" here? `add_llvm_pass_plugin` already uses CMake's object library via `add_llvm_library`. The problem I wanted to fix is `llvm_add_library` enforces the "Object Libraries" being built with `LLVM_BUILD_STATIC`.

In any case, I understand now that this approach is unlikely to be acceptable. If I can find an alternative approach, I'll open a new PR. Any suggestions would be greatly appreciated. Thank you.

https://github.com/llvm/llvm-project/pull/158023