LLD Standalone CMake build

I'm hoping to revive the LLD standalone CMake build. I'm new to this
build but it looks like it borrowed code from an old version of
compiler-rt, which I did some work on last year. Like compiler-rt,
I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH
instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and
LLD_PATH_TO_LLVM_SOURCE. Any objection to that?

Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp
include a private header from the LLVM source tree,
"llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the
dependency on HAVE_CXXABI_H be removed? If no, mind if I add a
config.h.cmake to LLD's "include/lld/Config"?

Thanks,
Greg

I'm hoping to revive the LLD standalone CMake build. I'm new to this
build but it looks like it borrowed code from an old version of
compiler-rt, which I did some work on last year. Like compiler-rt,
I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH
instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and
LLD_PATH_TO_LLVM_SOURCE. Any objection to that?

I think I don't have enough knowledge on the CMake build system to comment
on this. If no one objects and things keep working, that'd be fine to me.

Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp
include a private header from the LLVM source tree,
"llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the
dependency on HAVE_CXXABI_H be removed? If no, mind if I add a
config.h.cmake to LLD's "include/lld/Config"?

I believe that dependency cannot be removed since the code really needs to
know whether cxxabi.h is available or not. Feel free to add config.h.cmake
to include/lld/Config.

Why?

It adds complexity and cost to everyone who has to touch the build system.

Note that even if you're willing to "maintain" the standalone build, that
doesn't *really* fix the problem. Lots of folks will need to make changes
to the build system, and these types of different supported usage scenarios
make these much harder to think about, enact, and test.

Having to build and test and install using 3 or 4 different combinations of
standalone and not standalone is a complete nightmare. I'm pretty strongly
opposed to more standalone build support unless developers on the project
have really serious problems with IDE scaling.

Honestly, if we could fix the IDE scaling, I'd rip all of the standalone
build support out of all of our CMake builds.

I'm hoping to revive the LLD standalone CMake build.

Why?

Maintaining the standalone build allows us to purge dependencies on
internals of the LLVM build. In this case, it spotted a dependency on
a private header. It also points out the spots where the exported
CMake libraries depend on global variables set by LLVM's
CMakeLists.txt.

-Greg

I'm hoping to revive the LLD standalone CMake build.

Why?

It adds complexity and cost to everyone who has to touch the build system.

Note that even if you're willing to "maintain" the standalone build, that
doesn't *really* fix the problem. Lots of folks will need to make changes
to the build system, and these types of different supported usage scenarios
make these much harder to think about, enact, and test.

Having to build and test and install using 3 or 4 different combinations
of standalone and not standalone is a complete nightmare. I'm pretty
strongly opposed to more standalone build support unless developers on the
project have really serious problems with IDE scaling.

I doubt IDE scaling would be an issue in this particular scenario. LLD is
so small relative to LLVM that it shouldn't cause a noticeable burden for
the IDE.

-- Sean Silva

I'm hoping to revive the LLD standalone CMake build. I'm new to this
build but it looks like it borrowed code from an old version of
compiler-rt, which I did some work on last year. Like compiler-rt,
I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH
instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and
LLD_PATH_TO_LLVM_SOURCE. Any objection to that?

Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp
include a private header from the LLVM source tree,
"llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the
dependency on HAVE_CXXABI_H be removed? If no, mind if I add a
config.h.cmake to LLD's "include/lld/Config"?

I personally would be opposed to adding configure machinery to LLD's build.
It is just duplicating the machinery already in LLVM.

-- Sean Silva

How do you feel about adding LLD to the LLVM repo? Could it follow
the same path as the integrated assembler? That is, Clang keeps it
off by default for each architecture until it's ready for prime time.

-Greg

I know, that's why I'm not in favor of a standalone build.

While I'm not personally opposed to it, I think it's reasonable to avoid if
people want to not have the clutter of a linker when checking out and using
LLVM.

Having the stand alone build is a pretty big obstacle to build system
changes, so it's not just a maintenance problem. I'd rather we didn't
support it.

- Michael Spencer

If this ever happens, we *must* fix the coding style first. I would
also list as must fix before:

* check-all clean on a asan and msan build.
* -DBUILD_SHARED_LIBS=ON works.

Cheers,
Rafael

* fix the coding style first.
* check-all clean on a asan and msan build.
* -DBUILD_SHARED_LIBS=ON works.

I can take the ASan/MSan and build work. Fixing the coding style is
important, but must it be a gate? If so, can we push the patch for
lowerCamelCase local variables in the LLVM coding conventions before
there's a plan on how to transition the LLVM codebase?

Thanks,
Greg

Wait, huh?

I didn't think there was *any* consensus that this was the desired path
forward. I think Rafael was just listing things that would need to happen
*if* it were the path forward.

Wait, huh?

I didn't think there was *any* consensus that this was the desired path
forward. I think Rafael was just listing things that would need to happen
*if* it were the path forward.

Correct.

Cheers,
Rafael

I didn't think there was *any* consensus that this was the desired path forward. ...

Correct.

One step back then, do we have a consensus that the LLVM and LLD
coding standards should converge?

-Greg

There was a long thread about coding standards. This thread doesn't seem
like the right place to bring that back up. Either the old thread or a new
thread makes much more sense.

>> I didn't think there was *any* consensus that this was the desired path
forward. ...
> Correct.

One step back then, do we have a consensus that the LLVM and LLD
coding standards should converge?

Unless you want to have LLVM and LLD merged for some reason independently
of this patch, for now you can just assume LLVM and LLD will be separate.

-- Sean Silva