This is an archive of the discontinued LLVM Phabricator instance.

[cmake] Allow llvm_ExternalProject_Add to find CMAKE_SYSTEM_NAME among ${proj}_CMAKE_ARGS
AbandonedPublic

Authored by krisb on May 30 2020, 5:42 AM.

Details

Summary

llvm_ExternalProject_Add requires CMAKE_SYSTEM_NAME to be passed to set
correct toolchain tools, for example, for Windows.
But there are no other ways to do this for a default configuration of a
runtimes/builtins project, except using RUNTIMES_CMAKE_ARGS/BUILTINS_CMAKE_ARGS.
So, it is worth to account these variables while searching for CMAKE_SYSTEM_NAME.

Diff Detail

Event Timeline

krisb created this revision.May 30 2020, 5:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 30 2020, 5:42 AM

Hmm, this tries to extract CMAKE_SYSTEM_NAME from ..._CMAKE_ARGS if Im reading this correctly. Why not just say that you must pass CMAKE_SYSTEM_NAME via ..._CMAKE_ARGS rather than CMAKE_ARGS and just drop the clause above it?

compnerd added a subscriber: plotfi.Jun 8 2020, 9:35 AM

I am a little confused. Can you show an example of what would go in the cache file that would set what would otherwise be set by CMAKE_SYSTEM_NAME ?

krisb added a comment.Jun 9 2020, 4:26 AM

@compnerd @plotfi thank you for the comments! Sorry if the description looks confusing. I'll try to be more clear.
I'm trying to build something like

cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES=compiler-rt ../llvm

for host Windows under MSVC. This gives me the following error:

The Clang compiler tool

  "J:/llvm-project/build/./bin/clang.exe"

targets the MSVC ABI but has a GNU-like command-line interface.  This is
not supported.  Use 'clang-cl' instead, e.g.  by setting 'CC=clang-cl' in
the environment.

llvm_ExternalProject_Add sets to use clang-cl when _cmake_system_name is equal to Windows, but _cmake_system_name is defined only if -DCMAKE_SYSTEM_NAME is coming through CMAKE_ARGS.
This way perfectly works if runtimes/builtins are built for a known target, because we can pass RUNTIMES_${target}_CMAKE_SYSTEM_NAME and it will go to these CMAKE_ARGS.

Building for host (default) target there is no way to pass something to the CMAKE_ARGS.
I'm thinking... Maybe it would be better to do something similar for the default target and respect RUNTIMES_${var} or RUNTIMES_default_${var} inside the runtime_default_target() of llvm/runtimes/CMakeLists.txt (similarly as it is done for runtime_register_target())?
This can bring more flexibility.

I also found another attempt to handle CMAKE_SYSTEM_NAME for default target at https://reviews.llvm.org/D73811, but as far as I can see, it has been reverted.

Hmm, this tries to extract CMAKE_SYSTEM_NAME from ..._CMAKE_ARGS if Im reading this correctly. Why not just say that you must pass CMAKE_SYSTEM_NAME via ..._CMAKE_ARGS rather than CMAKE_ARGS and just drop the clause above it?

Hmm. I'm not sure this would work for runtimes/builtins if they are being built for a particular target. This would require to set CMAKE_SYSTEM_NAME through ${tagret}_CMAKE_ARGS and not as RUNTIMES_${target}_CMAKE_SYSTEM_NAME which looks as a more preferred way to me.

I am a little confused. Can you show an example of what would go in the cache file that would set what would otherwise be set by CMAKE_SYSTEM_NAME ?

Sorry, seems I didn't get your question. Did you mean what vars/options would be set depending on CMAKE_SYSTEM_NAME? If so, I'm mostly talking about a compiler (i.e. clang-cl.exe instead of clang.exe).

krisb added a comment.Jun 15 2020, 1:55 PM

@plotfi @compnerd
I created another review with an alternative solution at D81877. I'll appreciate if you have a chance to look at it. Thank you.

krisb abandoned this revision.Jun 20 2020, 1:46 AM