This is an archive of the discontinued LLVM Phabricator instance.

[lit] Update how clang and other binaries are found in per-configuration directories
ClosedPublic

Authored by asmith on Feb 8 2018, 4:01 PM.

Details

Summary

This is modeled after the clang and llvm lit tests.

Several properties have CMAKE_CFG_INTDIR as part of the path - this works correctly when the cmake generator only supports one configuration which is known at configuration time, but it does not work correctly when the cmake generator supports multiple configurations (for example, VS).

For VS, CMAKE_CFG_INTDIR ends up set as $Configuration and then it is never updated correctly. Instead, the lit configuration can use a property that can be overwritten at run time. AddLLVM does that for several properties (such as LLVM_TOOLS_DIR).

This change is also removing properties from the lit/CMakeLists.txt that are actually set during the call to configure_lit_site_cfg

Diff Detail

Repository
rL LLVM

Event Timeline

asmith created this revision.Feb 8 2018, 4:01 PM
zturner added inline comments.Feb 8 2018, 4:15 PM
lit/CMakeLists.txt
10–13

This only works if you're using a just-built clang, which might not be the case. In fact, it's usually not the case, because it's common to want to run the test suite against a debug build of lldb but using a release build of clang (otherwise you'll be there all day waiting for it to finish).

I feel like if the user specifies an absolute path to the test compiler on the command line, that should be what it uses -- always. If we want to use a just built toolchain, maybe we need something else, like -DLLDB_TEST_BUILT_CLANG=ON, which would trigger this logic.

As I don't use this configuration though, I'm interested in hearing your thoughts.

lit/CMakeLists.txt
10–13

It actually does work in the case when a user specifies a compiler on the command line as well as when the just-built clang is used and the default today is to use the just-built clang.

As far as I can tell, you can specify the compiler with LLDB_TEST_C_COMPILER (or LLDB_TEST_CXX_COMPILER) when calling CMake or by passing a value to the tests directly with -C. I assume that you are concerned about the first case - when passing the property to CMake?

In that case LLDB_TEST_C_COMPILER is set to /path/to/compiler and these lines won't actually affect it - unless for some reason the path contained ${CMAKE_CFG_INTDIR}. If ${CMAKE_CFG_INTDIR} is a period, which is the likely scenario, it will just be replaced by another period since the build mode would be the same.

The only case when it might not work is if ${CMAKE_CFG_INTDIR} is in the path but not a period - but that is unlikely since the scenario would mean that ${CMAKE_CFG_INTDIR} is, say, $Configuration and the path that the user specified contains $Configuration AND it is different than the one they're using for LLDB.

On the other hand, without this change it is not possible to use the just-built compiler when using Visual Studio, for example, because the path to the just built compiler is not being set correctly and this particular substitution needs to happen here.

The way to make sure that both scenarios work always is to guard against the substitution when the user explicitly specifies a path or to enforce the sibstitution when they're using the just-built clang so a property like LLDB_TEST_BUILD_CLANG would work. If you think that the error scenario is likely enough, then we should add the property.

lit/CMakeLists.txt
10–13

Actually, I misspoke. There is another way to do it without an extra property that the user has to pass.

Right now, in the main CMakeLists.txt for LLDB, we create a property LLDB_DEFAULT_TEST_C_COMPILER which overwrites LLDB_TEST_C_COMPILER if LLDB_TEST_C_COMPILER is not set by the user. We could at that point first check whether LLDB_TEST_C_COMPILER was explicitly set and internally create a property to tell us whether to overwrite later. I think that may actually be better since it maintains the current behavior and there's no need for a new explicit property.

Thoughts?

asmith updated this revision to Diff 133770.Feb 10 2018, 2:33 PM
labath added a subscriber: labath.Feb 12 2018, 3:02 AM
labath added inline comments.
CMakeLists.txt
79–86

I don't think this will work the second time you run cmake (i.e., re-run cmake in an already-initialized build directory) as then this would pick up the cached value from the previous cmake run.

I think a least magic solution would be to have a cmake option to specify whether you are overriding the compiler, defaulting to off (and in that case these cache values would be ignored).

asmith updated this revision to Diff 133899.Feb 12 2018, 10:33 AM
asmith marked 4 inline comments as done.Feb 13 2018, 10:17 AM
zturner accepted this revision.Feb 20 2018, 10:52 AM
This revision is now accepted and ready to land.Feb 20 2018, 10:52 AM
asmith closed this revision.Feb 20 2018, 4:07 PM