[PATCH] D119049: [LLD] Allow usage of LLD as a library

[Alexandre Ganea via Phabricator via llvm-commits]

aganea added inline comments.


================
Comment at: lld/Common/DriversMain.cpp:163-172
+    if (f == MinGW)
+      return mingw::link;
+    else if (f == Gnu)
+      return elf::link;
+    else if (f == WinLink)
+      return coff::link;
+    else if (f == Darwin)
----------------
jerryyin wrote:
> I have a naïve question to ask:
>  - In my limited knowledge, previously `lldELF` is dependent on `lldCommon` target. `lld.cpp` would compile just fine because its target is an executable.
>  - Now, since `DriversMain.cpp` become part of `lldCommon`, and in the implementation of `DriversMain,cpp`, we start to invoke those specific link target, it implicitly requires, for example, `lld::elf::link` to be available before `lldCommon` is compiled. In other words, `lldCommon` is dependent on `lldELF`. 
> 
> Did we just have a cyclic dependency here? And if it is, do you need to move the `lldMain()` and `safeLldMain()` into their own independent target such that we can avoid the existence of such a cycle in the compilation?
The trickery is that we push lldCommon twice on the command-line, [[ https://github.com/llvm/llvm-project/blob/main/lld/ELF/CMakeLists.txt#L77 | once in lldELF ]] (same in all the other drivers), in another time in [[ https://github.com/llvm/llvm-project/blob/main/lld/tools/lld/CMakeLists.txt#L23 | the final module ]]. I retained the same mechanic for the unittests.

We could have another lib for LLD-as-lib usage, but I thought from the users' perspective it's simpler if we provided a single "common" lib + the specific drivers' libs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119049