This is an archive of the discontinued LLVM Phabricator instance.

clang/cmake: Require pre-built test dependencies for stand-alone builds
Needs ReviewPublic

Authored by tstellar on Nov 8 2022, 1:22 PM.

Details

Summary

If the FileCheck, count, and not tools are not found in
LLVM_TOOLS_BINARY_DIR, then tests will be disabled. CMake will
no longer try to build these tool from the llvm sources.

In theory, since stand-alone builds are meant to be done without
access to the llvm sources, this should be a no-op, but this
change will affect anyone trying to do stand-alone builds with
the full monorepo sources.

Diff Detail

Event Timeline

tstellar created this revision.Nov 8 2022, 1:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 8 2022, 1:22 PM
tstellar requested review of this revision.Nov 8 2022, 1:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 8 2022, 1:22 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

This does, somewhat, coincide with what I'm trying to do in D131052. There, I don't point out the binaries for FileCheck and similar, but point out preexisting native llvm-tblgen, clang-tblgen etc (to avoid needing to build them in a nested native cmake when cross compiling) - but if they exist, they would probably be in the same directory. Would it make sense to try to settle on a common variable name for both of these? Or is there a case where we specifically need to be able to differentiate between the two?

CC @smeenai

(I haven't gotten around to refreshing that patch yet, unfortunately.)

Could you issue a warning though? It's really annoying when targets disappear like that and you have to guess which of the checks failed.

Could you issue a warning though? It's really annoying when targets disappear like that and you have to guess which of the checks failed.

What about just making it an error if LLVM_INCLUDE_TESTS is set, but it kind find all the tools? I also don't like the silent disabling of features, but I'm not sure how visible the warning would be to users.

I don't have a strong opinion. I'm happy as long as there is *anything* telling me "tests were disabled because ...".

Also FYI, OpenMP has a bit of prior art in this area - see e.g. https://github.com/llvm/llvm-project/blob/main/openmp/cmake/OpenMPTesting.cmake#L27-L36. There it prints a warning at cmake time, disabling tests, saying why, and giving hints about how to fix it.

This does, somewhat, coincide with what I'm trying to do in D131052. There, I don't point out the binaries for FileCheck and similar, but point out preexisting native llvm-tblgen, clang-tblgen etc (to avoid needing to build them in a nested native cmake when cross compiling) - but if they exist, they would probably be in the same directory. Would it make sense to try to settle on a common variable name for both of these? Or is there a case where we specifically need to be able to differentiate between the two?

Do you mean creating a common variable name for the path to llvm utils?

This does, somewhat, coincide with what I'm trying to do in D131052. There, I don't point out the binaries for FileCheck and similar, but point out preexisting native llvm-tblgen, clang-tblgen etc (to avoid needing to build them in a nested native cmake when cross compiling) - but if they exist, they would probably be in the same directory. Would it make sense to try to settle on a common variable name for both of these? Or is there a case where we specifically need to be able to differentiate between the two?

Do you mean creating a common variable name for the path to llvm utils?

Yes, exactly. The use cases are maybe slightly separate, but still, in both cases it'd be a path to a directory containing native versions of not, FileCheck, llvm-tblgen etc.