[libcxx-commits] [PATCH] D150766: [libcxx] [ci] Add a test configuration with an incomplete sysroot

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/utils/ci/run-buildbot:648
 ;;
+mingw-incomplete-sysroot)
+    clean
----------------
ldionne wrote:
> Is there a reason why we're running this on MinGW? It would make more sense IMO to do this in our Docker image on Linux. At the end of the day, we are trying to test a general property of our CMake build, i.e. that it can be run even if you don't have access to a fully working C++ toolchain. This isn't Windows-specific, right?
Indeed it isn't Windows specific per se.

But in most cases on e.g. Linux, you'd already have a working toolchain with libgcc provided by the system. For the case of something that mostly behaves as a cross compiler (i.e. there's no such thing as a system provided libgcc or similar), it's easier to produce a stripped down sysroot and reach such a state.

The same goes for the actual bringup of a toolchain, where you'd have such an incomplete stage; when building a non-cross toolchain, you're usually already operating on top of a working environment, so you usually don't pass through that incomplete state.

(There's of course small nuances that do differ between systems wrt how they behave in an incomplete state, e.g. ELF usually is more tolerant against undefined symbols than what PE/COFF is.)

If configuring a toolchain where the compiler uses libunwind by default, and libunwind doesn't exist yet, then you'd have the same situation on Linux too. The main thing that is relevant is that you'd have a clang setup for a target where just invoking `clang` without any flags tries to link libunwind by default.


Regarding Docker - if I understood correctly, the current setup is that we're running Docker containers, which then run the buildkite agent within them, serving multiple build jobs within the same persistent Docker container. If the setup would be the reverse - each buildkite job spawning a new individual Docker container, then this setup would be easier to more properly simulate an incomplete situation. Instead of setting up and stripping down a sysroot, the actual system toolchain could be stripped in a matching fashion.


In other words: I was easily able to set this up, and this gives test coverage of the bringup phase of my toolchain. If soomeone else wants to try to set up a similar test scenario within the Linux test configs, feel free to, but for me, that'd be significantly more effort to set up.

The case that this covers is literally something that every one of @phosek's refactorings to `runtimes/CMakeFiles.txt` hits and needs to test.


================
Comment at: libcxx/utils/ci/run-buildbot:675
+          -DCMAKE_C_COMPILER_WORKS=TRUE \
+          -DCMAKE_CXX_COMPILER_WORKS=TRUE \
+          -DCMAKE_C_COMPILER_TARGET=x86_64-w64-windows-gnu \
----------------
ldionne wrote:
> I would set this unconditionally in `runtimes/CMakeLists.txt` with an appropriate comment. I don't think it ever makes sense for us to rely on the default CMake compiler checking.
Hmm, I wonder if it's possible (and generally advisable?) to do that. WDYT @phosek?


================
Comment at: libcxx/utils/ci/run-buildbot:681-683
+    # Additionally, the sysroot flag from CMAKE_SYSROOT doesn't end up
+    # propagated into the tests at the moment (neither do flags set via
+    # CMAKE_*_FLAGS).
----------------
ldionne wrote:
> > Additionally, the sysroot flag from CMAKE_SYSROOT doesn't end up propagated into the tests
> 
> This shouldn't matter, since we're using `-nostdlib++` and `-nostdinc++` to avoid depending on any existing libc++ in the toolchain.
It's not so much about libc++ as it is about libunwind and all that. If the toolchain default sysroot is fully functional with a working libunwind, and the intentionally stripped down sysroot lacks libunwind, then testing without the `--sysroot` parameter loses that distinction, even if `-nostdlib++` avoids using the default C++ library.

But in any case, this configuration is mostly interesting for compiling the runtimes, once built it should mostly behave as any other build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150766