[PATCH] D87418: [LLD] Allow configuring default ld.lld backend

Thu Sep 10 14:39:14 PDT 2020

mati865 added a comment.

> How widespread are these build systems that parse help output? (Given that it took until now to discover them, I'd venture "not very".)

This was well known limitation but also seen as "not a big deal" because LLD wasn't used broadly.

Basically any package at https://github.com/msys2/MINGW-packages which uses autotools build system is more or less affected. It's possible that MSYS2 will soon get new subsystem that uses LLVM project as the main compiler.

> Maybe it would be better to fix them to explicitly pass -m and/or do something that doesn't rely on parsing help output (e.g. just try the flag and see whether it fails).

Patching `configure` script of all affected packages every time they are updated is enormous task.
It basically comes to downstream vs upstream patches.

> for e.g. msys2, it would make sense to have an ld.lld.exe that on its own, without any options, defaults to the local native target, and would work just like ld.bfd.exe (which afaik works without an -m option) in that sense

It also often confuses users who expect `ld.lld --help` to print MinGW help just like `ld.bfd --help` does.

================
Comment at: lld/CMakeLists.txt:196

+set(LLD_DEFAULT_LD_LLD_BACKEND "ELF"
+    CACHE STRING "Default backend for ld.lld, can be either ELF (default) or MINGW")
----------------
MaskRay wrote:
> pcc wrote:
> > MaskRay wrote:
> > > How about a boolean variable `LLD_DEFAULT_LD_LLD_IS_MINGW`?
> > > 
> > > Then you can write `#if LLD_DEFAULT_LD_LLD_IS_MINGW`, a Bazel based build system which does not need to this variable (my users) does not need any change.
> > > Additionally, the gn build will not break.
> > The other build systems aren't really supported though, so we should probably do whatever makes sense for the cmake build and let the other build systems deal with it.
> If mingw is an anomaly, I think a boolean variable makes more sense than a string variable with multiple values. The convenience for other build systems is a  byproduct.
That was my initial attempt...

I thought the other targets in the future could need the same thing so I replaced it with generic solution.

I'm fine either way.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87418