cmake fill `cmake_args` when cross-compiling external project with non-clang compiler

This makes it possible to crosscompile runtimes with cl.exe on Windows.

An external project is completely misco

cmake fill `cmake_args` when cross-compiling external project with non-clang compiler

This makes it possible to crosscompile runtimes with cl.exe on Windows.

An external project is completely misconfigured otherwise because
cmake_args is set only for native builds or builds crosscompiled with
clang.

Differential Revision: https://reviews.llvm.org/D122578
Reviewed By: beanz, compnerd

show more ...

Revert "[runtimes] Detect changes to Tests.cmake"

This reverts commit ec10ac750a8ad96983d85263323635f3dabe92fd.

See https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788.
This change caus

Revert "[runtimes] Detect changes to Tests.cmake"

This reverts commit ec10ac750a8ad96983d85263323635f3dabe92fd.

See https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788.
This change caused Ninja's CMake regeneration to depend on the build,
which prevented CMake regeneration from functioning properly and caused
spurious build failures on incremental builds when a CMake change
occurred.

show more ...

[runtimes] Detect changes to Tests.cmake

This ensures that Tests.cmake is tracked by Ninja and any changes to
this file from the subbuilds are correctly detected.

Differential Revision: https://rev

[runtimes] Detect changes to Tests.cmake

This ensures that Tests.cmake is tracked by Ninja and any changes to
this file from the subbuilds are correctly detected.

Differential Revision: https://reviews.llvm.org/D121647

show more ...

[CMake] Pass CMAKE_C/CXX_COMPILER_LAUNCHER down to cross-compile and runtime build

Similar to D59032.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D117746

[CMake] Support passing arguments to build tool for external projects

Add CMake variable LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS to allow
arguments to be passed to the native tool used in CMake --buil

[CMake] Support passing arguments to build tool for external projects

Add CMake variable LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS to allow
arguments to be passed to the native tool used in CMake --build
invocations for external projects.

Can be used to pass extra arguments for enhanced versions of build
tools, e.g. distributed build options.

Differential Revision: https://reviews.llvm.org/D115815

show more ...

[CMake] Pass through CMAKE_READELF to subbuilds

This matches handling of other CMake variables.

Differential Revision: https://reviews.llvm.org/D110463

[CMake] Pass llvm-readelf to CMake external builds

This matches other LLVM binary tools.

Differential Revision: https://reviews.llvm.org/D110313

[runtimes] Fix crosscompiling after a7cad6680b4087eff8994f1f99ac40c661a6621f (D97451)

It moved the logic for CMake target arguments into llvm_ExternalProject_Add().
No handling was added for CMAKE_C

[runtimes] Fix crosscompiling after a7cad6680b4087eff8994f1f99ac40c661a6621f (D97451)

It moved the logic for CMake target arguments into llvm_ExternalProject_Add().
No handling was added for CMAKE_CROSSCOMPILING, which has a separate set of compiler_args.
This broke crosscompiling, as now the runtimes builds defaulted to the compiler's default.

I've also added passing of CMAKE_ASM_COMPILER, which was missing before although we were passing the triple for it.

Reviewed By: zero9178

Differential Revision: https://reviews.llvm.org/D97855

show more ...

[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add

Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC

[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add

Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment.

This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.

show more ...

[CMake][AIX] Limit tools in external project build

This is a follow on to D85329 which disabled some llvm tools in the
runtimes build due to XCOFF64 limitations. This change disables them
in other e

[CMake][AIX] Limit tools in external project build

This is a follow on to D85329 which disabled some llvm tools in the
runtimes build due to XCOFF64 limitations. This change disables them
in other external project builds as well, when no list of tools is
specified in the arguments.

Reviewed By: hubert.reinterpretcast, stevewan

Differential Revision: https://reviews.llvm.org/D88310

show more ...

[CMake] Make sure _cmake_system_name has a default

We currently try to pick it up from the CMake arguments passed to llvm_ExternalProject_Add but
if there isn't an explicit option passed, we should

[CMake] Make sure _cmake_system_name has a default

We currently try to pick it up from the CMake arguments passed to llvm_ExternalProject_Add but
if there isn't an explicit option passed, we should reflect CMake's own default behaviour
of targeting the host, since we'll make decisions about what tools to use for the build based on
the setting. Otherwise, we'll get different behaviour between configuring an external project with
the default target and configuring with an explicit one targeting the same platform.

Reviewed By: stevewan, hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D88157

show more ...

Explicitly specify CMAKE_AR in WinMsvc.cmake

As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
https://gitlab.kitware.com/cmake/cmake/-/commit/55196a1440e26917d40e6a7a3e

Explicitly specify CMAKE_AR in WinMsvc.cmake

As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
https://gitlab.kitware.com/cmake/cmake/-/commit/55196a1440e26917d40e6a7a3eb8d9fb323fa657)
and now finds llvm-ar instead of llvm-lib as CMAKE_AR. This explicitly
specifies CMAKE_AR as llvm-lib so the correct program is found.

Reviewed By: smeenai

Differential Revision: https://reviews.llvm.org/D88176

show more ...

[runtimes] Use llvm-libtool-darwin for runtimes build

It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
rest

[runtimes] Use llvm-libtool-darwin for runtimes build

It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D86367

show more ...

[cmake] Don't use ld.lld when targeting Darwin

ld.lld is an ELF linker. We can switch to the new LLD for Mach-O port
when it's more complete, but for now, assume the user will have set
CMAKE_LINKER

[cmake] Don't use ld.lld when targeting Darwin

ld.lld is an ELF linker. We can switch to the new LLD for Mach-O port
when it's more complete, but for now, assume the user will have set
CMAKE_LINKER correctly themselves when targeting Darwin.

show more ...

[compiler-rt][CMake] Pass down LLVM_LIT_ARGS in runtime build

We should also pass down the LLVM_LIT_ARGS in runtime build mode,
so that the runtime tests can be well controlled as well.

We actually

[compiler-rt][CMake] Pass down LLVM_LIT_ARGS in runtime build

We should also pass down the LLVM_LIT_ARGS in runtime build mode,
so that the runtime tests can be well controlled as well.

We actually passed this down in clang/runtime/CMakeLists.txt
But not for calls from llvm/runtime/CMakeLists.txt.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D83565

show more ...

[cmake] Only set deps for an ExternalProject if the type is executable or library

Summary:
cmake fails with an error when attempting to evaluate $<TARGET_FILE:tgt>
where `tgt` is defined via an `add

[cmake] Only set deps for an ExternalProject if the type is executable or library

Summary:
cmake fails with an error when attempting to evaluate $<TARGET_FILE:tgt>
where `tgt` is defined via an `add_custom_target` and thus the `TYPE`
is `UTILITY`. Requesting a TARGET_FILE only works on an `EXECUTABLE`
or one of a few differetnt types of `X_LIBRARY` (e.g. added via
`add_library` or `add_executable`). The logic as implemented in cmake
is below:

enum TargetType
{
EXECUTABLE,
STATIC_LIBRARY,
SHARED_LIBRARY,
MODULE_LIBRARY,
OBJECT_LIBRARY,
UTILITY,
GLOBAL_TARGET,
INTERFACE_LIBRARY,
UNKNOWN_LIBRARY
};

if (target->GetType() >= cmStateEnums::OBJECT_LIBRARY &&
target->GetType() != cmStateEnums::UNKNOWN_LIBRARY) {
::reportError(context, content->GetOriginalExpression(),
"Target \"" + name +
"\" is not an executable or library.");
return nullptr;
}

This has always been the case back to at least 3.12 (furthest I
checked) but this is causing a new failure in cmake 3.17 while
evaluating ExternalProjectAdd.

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77284

show more ...

[CMake] Enable the use of -ffile-prefix-map

This handles not paths embedded in debug info, but also in sources.
Since the use of this flag is controlled by an option, rather than
replacing the new o

[CMake] Enable the use of -ffile-prefix-map

This handles not paths embedded in debug info, but also in sources.
Since the use of this flag is controlled by an option, rather than
replacing the new option, we add a new option.

Differential Revision: https://reviews.llvm.org/D76018

show more ...

[CMake] Use LLVM tools external project build where possible

This reduces the reliance on host tools and makes the build more
hermetic. Some of the runtimes already assume that certain tools are
alw

[CMake] Use LLVM tools external project build where possible

This reduces the reliance on host tools and makes the build more
hermetic. Some of the runtimes already assume that certain tools are
always available, for example libc++ and libc++abi archive merging
relies on ar to extract files out of the archive, even on Darwin.

Differential Revision: https://reviews.llvm.org/D74107

show more ...

[CMake] Set ASM compiler for external projects

This is necessary on Windows, otherwise CMake fails. It's not
conventional on Windows to use cl for assembly (you'd use ml or ml64
instead), but CMake

[CMake] Set ASM compiler for external projects

This is necessary on Windows, otherwise CMake fails. It's not
conventional on Windows to use cl for assembly (you'd use ml or ml64
instead), but CMake has a separate ASM_MASM mode for that, and clang-cl
works fine for assembly so we'll use that on Windows for consistency.

Differential Revision: https://reviews.llvm.org/D73522

show more ...

[llvm] Add llvm-lipo dependency to runtimes

Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencie

[llvm] Add llvm-lipo dependency to runtimes

Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencies lists.

Reviewers: alexshap, beanz, phosek, compnerd, smeenai, mtrent, plotfi, xiaobai

Reviewed By: phosek, smeenai

Subscribers: smeenai, mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71429

show more ...

Append an executable suffix to the toolchain tool paths on Windows platform.

Append a default CMake suffix (CMAKE_EXECUTABLE_SUFFIX) for the build host to the toolchain tool path when adding a LLVM

Append an executable suffix to the toolchain tool paths on Windows platform.

Append a default CMake suffix (CMAKE_EXECUTABLE_SUFFIX) for the build host to the toolchain tool path when adding a LLVM external project.
The tool binary files should contain .exe suffix to run them properly on Windows platform when building the projects.

Patch by Vlad Vereschaka.

Differential Revision: https://reviews.llvm.org/D65824

llvm-svn: 368121

show more ...

[CMake] Provide an option to use relative paths in debug info

CMake always uses absolute file paths in the generated compiler
invocation which results in absolute file paths being embedded in debug

[CMake] Provide an option to use relative paths in debug info

CMake always uses absolute file paths in the generated compiler
invocation which results in absolute file paths being embedded in debug
info. This is undesirable when building a toolchain e.g. on bots as the
debug info may embed the bot source checkout path which is meaningless
anywhere else.

This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses
-fdebug-prefix-map (where supported) options to rewrite paths embedded
into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can
be used to override the path to source directory with a different one.

Differential Revision: https://reviews.llvm.org/D62622

llvm-svn: 362185

show more ...

build: use clang-cl for runtimes when targeting Windows

When targeting Windows and building a runtime (subproject) prefer to use
`clang-cl` rather than the `clang` driver. This allows us to cross-c

build: use clang-cl for runtimes when targeting Windows

When targeting Windows and building a runtime (subproject) prefer to use
`clang-cl` rather than the `clang` driver. This allows us to cross-compile
runtimes for the Windows environment from Linux.

llvm-svn: 361072

show more ...

[cmake] Remove use of deprecated generator expression. NFC

Use $<CONFIG> instead of $<CONFIGURATION>, since the latter has been
deprecated since CMake 3.0, and the former is entirely equivalent.

ll

[cmake] Remove use of deprecated generator expression. NFC

Use $<CONFIG> instead of $<CONFIGURATION>, since the latter has been
deprecated since CMake 3.0, and the former is entirely equivalent.

llvm-svn: 357338

show more ...

[CMake] Support stripping and linking output to .build-id directory

When installing runtimes with install-runtimes-stripped, we don't want
to just strip them, we also want to preserve the debugging

[CMake] Support stripping and linking output to .build-id directory

When installing runtimes with install-runtimes-stripped, we don't want
to just strip them, we also want to preserve the debugging information
for potential debugging. To make it possible to later find the stripped
debugging information, we want to use the .build-id layout:

https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID

That is, for libfoo.so with build ID abcdef1234, the debugging information
will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy
already has support for stripping files and linking the debugging
stripped output into the right location. However, CMake doesn't support
customizing strip invocation for the *-stripped targets. So instead, we
replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with
the right command line flags.

Differential Revision: https://reviews.llvm.org/D59127

llvm-svn: 355765

show more ...