This is an archive of the discontinued LLVM Phabricator instance.

[CMake] Prefer multi-target variables over generic target variables in runtimes build
ClosedPublic

Authored by JamesNagurne on Dec 16 2019, 2:14 PM.

Details

Summary

Runtimes variables in a multi-target environment are defined like:

RUNTIMES_target_VARIABLE_NAME
RUNTIMES_target+multi_VARIABLE_NAME

In my case, I have a downstream runtimes cache that does the following:

set(RUNTIMES_${target}+except_LIBCXXABI_ENABLE_EXCEPTIONS ON CACHE BOOL "")
set(RUNTIMES_${target}_LIBCXX_ENABLE_EXCEPTIONS OFF CACHE BOOL "")

I found that I was always getting the 'target' variable value (OFF) in my 'target+except' build, which was unexpected.
This behavior was caused by the loop in llvm/runtimes/CMakeLists.txt that runs through all variable names, adding '-DVARIABLE_NAME=' options to the subsequent external project's cmake command.

The issue is that the loop does a single pass, such that if the 'target' value appears in the cache after the 'target+except' value, the 'target' value will take precedence. I suggest in my change here that the more specific 'target+except' value should take precedence always, without relying on CMake cache ordering.

Diff Detail

Event Timeline

JamesNagurne created this revision.Dec 16 2019, 2:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 16 2019, 2:14 PM

I'm fine with this change in general, but I'm concerned that no matter what order we choose, this might break users who rely on the opposite order. Maybe it'd be better to modify the logic to skip the second loop if the first loop matches, that way we wouldn't rely on any particular order.

I'm fine with this change in general, but I'm concerned that no matter what order we choose, this might break users who rely on the opposite order. Maybe it'd be better to modify the logic to skip the second loop if the first loop matches, that way we wouldn't rely on any particular order.

I've implemented the proposed idea in D71737.

I'm fine with this change in general, but I'm concerned that no matter what order we choose, this might break users who rely on the opposite order. Maybe it'd be better to modify the logic to skip the second loop if the first loop matches, that way we wouldn't rely on any particular order.

I think the problem is the behavior wasn't defined at all before, and relied on how cmake defined the variables in the LLVM project cmake cache file.

What I wrote in my runtimes cache file:

  • RUNTIMES_target_VARIABLE=123
  • RUNTIMES_target+multi_VARIABLE=456

What I got in LLVM's CMakeCache.txt

  • RUNTIMES_target+multi_VARIABLE=456
  • RUNTIMES_target=VARIABLE=123

What I expected in CMakeCache.txt:

  • RUNTIMES_target=VARIABLE=123
  • RUNTIMES_target+multi_VARIABLE=456

The result: VARIABLE in the target+multi runtime project was 123 instead of 456

While we might break projects, I believe that this solves the problem of relying on some internal cmake or system behavior (I don't know why the resulting CMakeCache.txt is out-of-order, haven't dug that deep), while allowing users to get whatever behavior they want.

phosek accepted this revision.Dec 20 2019, 5:05 PM

LGTM

This revision is now accepted and ready to land.Dec 20 2019, 5:05 PM

Sadly, I do not have commit access. Could you do the honors @phosek ?

@phosek or really any other committer, could we get this onto master?

We have the change locally, but think it'd be nice to have it upstreamed so it doesn't get stale.

Thanks!

This revision was automatically updated to reflect the committed changes.