Page MenuHomePhabricator

[CMake] Explicitly specify paths to libc++abi in CrossWinToARMLinux.cmake

Authored by broadwaylamb on Feb 10 2020, 10:29 AM.



D69169, which was necessary for running libc++ tests on remote host, got reverted. I couldn't think of a less invasive way to achieve this behavior but specify libc++abi paths in our cache file.

I was wondering though if the assumptions I made in this patch regarding directory layout always hold.

Diff Detail

Event Timeline

broadwaylamb created this revision.Feb 10 2020, 10:29 AM
This revision is now accepted and ready to land.Feb 12 2020, 3:37 PM
This revision was automatically updated to reflect the committed changes.
broadwaylamb reopened this revision.Mar 11 2020, 3:15 PM
This revision is now accepted and ready to land.Mar 11 2020, 3:15 PM

Add one more libc++abi header search path when building libc++

@vvereschaka this is supposed to fix the buildbot failure. It's more of a sweep under the rug type of fix. The real problem is that the value of the CMAKE_SOURCE_DIR variable is unexpected.

See for yourself.

Before 0197eac3330c04a49519f3e4dac38c4de605c654 I had the following in the build log:

-- Looking for cxxabi.h in C:/buildbot/as-builder-1/llvm-clang-win-x-armv7l/llvm-project/libcxxabi/include - found

After (note the missing 'llvm-project' component in the path):

-- Looking for cxxabi.h in C:/buildbot/as-builder-1/llvm-clang-win-x-armv7l/libcxxabi/include - not found

Maybe you have an idea of why this is happening? This all works fine on my machine even if I reproduce the directory layout used on the buildbot and invoke CMake from the build directory:

broadwaylamb requested review of this revision.Mar 11 2020, 3:38 PM

I tried to reproduce the problem on the builder in a temporary folder and I found that CMAKE_SOURCE_DIR == CMAKE_BINARY_DIR == <build_dir>.
Here is a list of all CMAKE_ variables available on a moment of initial configuration:

-- CMAKE_AR: c:/buildbot/temp/build/bin/llvm-ar.exe
-- CMAKE_BINARY_DIR: C:/buildbot/temp/build
-- CMAKE_CL_SHOWINCLUDES_PREFIX: Note: including file:
-- CMAKE_COMMAND: C:/Program Files/CMake/bin/cmake.exe
-- CMAKE_CPACK_COMMAND: C:/Program Files/CMake/bin/cpack.exe
-- CMAKE_CTEST_COMMAND: C:/Program Files/CMake/bin/ctest.exe
-- CMAKE_CURRENT_BINARY_DIR: C:/buildbot/temp/build
-- CMAKE_CURRENT_LIST_DIR: C:/buildbot/temp/llvm-project/clang/cmake/caches
-- CMAKE_CURRENT_LIST_FILE: C:/buildbot/temp/llvm-project/clang/cmake/caches/CrossWinToARMLinux.cmake
-- CMAKE_CURRENT_SOURCE_DIR: C:/buildbot/temp/build
-- CMAKE_C_COMPILER_TARGET: armv7-linux-gnueabihf
-- CMAKE_ROOT: C:/Program Files/CMake/share/cmake-3.10
-- CMAKE_SOURCE_DIR: C:/buildbot/temp/build
-- CMAKE_VERSION: 3.10.2

Looks like this is a feature (bug?_ of CMake. CMake doc says

The path to the top level of the source tree.

This is the full path to the top level of the current CMake source tree. For an in-source build, this would be the same as CMAKE_BINARY_DIR.

When run in -P script mode, CMake sets the variables CMAKE_BINARY_DIR, CMAKE_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR to the current working directory.

-C could be some kind of the script mode. May be. We use CMake 3.10.2 on the builders.

I think may be it is optimal to use CMAKE_CURRENT_LIST_DIR to calculate a direct path to required file. We always know where it is.

Something like that

                       ABSOLUTE CACHE)

@vvereschaka very interesting. I've downloaded CMake 3.10.2 and finally been able to reproduce the issue locally. So it is a CMake bug which does not appear in the latest versions. I'll update this patch to use CMAKE_CURRENT_LIST_DIR and add a comment.

Use CMAKE_CURRENT_LIST_DIR instead of CMAKE_SOURCE_DIR for locating the llvm-project directory.

I was able to build with these changes successfully on the local builder host.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 13 2020, 8:01 AM
This revision was automatically updated to reflect the committed changes.