[PATCH] D133475: [docs] Fix build-docs.sh

[Tobias Hieta via Phabricator via llvm-commits]

thieta added a comment.

In D133475#3800522 <https://reviews.llvm.org/D133475#3800522>, @ldionne wrote:

> Okay, I looked into it and the issue is basically that `libcxx-abi-shared` does not exist when `libcxxabi` is not in `LLVM_ENABLE_RUNTIMES`. That's normally okay, except when we generate a linker script in place of `libc++.so` (aka on Linux), since that requires resolving the ABI library's target to know to add `-lc++abi`. I would normally expect that generator expressions inside the linker script generation are only evaluated if we actually perform the `POST_BUILD` step it's associated to, but that's not how CMake works. It seems to eagerly evaluate the generator expressions, leading to problems since at least one of them is invalid.

I have solved similar problems in CMake before by having a separate script that's called from POST_BUILD with `cmake -E script <script_path>` where the script can be configured with a `configure_file()` in cmake to inject variables. It's not great, but it's a working portable solution.

> Potential fixes:
>
> 1. When specifying `LIBCXX_CXX_ABI=libcxxabi` (which is also the default), we could implicitly add `LLVM_ENABLE_RUNTIMES=libcxxabi`.
> 2. We could mandate that users pass `LLVM_ENABLE_RUNTIMES=libcxxabi` when they select `LIBCXX_CXX_ABI=libcxxabi`. We would add a proper diagnostic to avoid confusing users. Since `LIBCXX_CXX_ABI=libcxxabi` is the default, that would mean that most users would suddenly have to specify `LLVM_ENABLE_RUNTIMES=libcxxabi` if they don't already do it.
> 3. Add a narrow workaround for the problem by e.g. not creating a linker script if `libcxx-abi-shared` is not present. This is kind of hacky, since it would mean that e.g. running `ninja install-cxx` would result in a malfunctioning libc++ installation on Linux, and that would be silent.
>
> (2) seems like a lot of breakage and user-facing complexity for little to no benefit.
> (3) seems like the worst of both worlds, where we set ourselves up for silent problems down the road.
>
> Therefore, I conclude that the best way forward would be (1). I also think it's kind of weird to do that, but all the other options really don't make sense to me.

I think you are right - but it would have to be logged as a warning I think.

> So as far as I'm concerned, you can ship this to unblock you in the short term. However, I'll look into doing (1) and landing that for LLVM 16.

Thanks, will do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133475