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
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
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
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.
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
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
As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
55196a1440)
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
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
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.
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
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
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
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
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
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
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
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
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
Use $<CONFIG> instead of $<CONFIGURATION>, since the latter has been
deprecated since CMake 3.0, and the former is entirely equivalent.
llvm-svn: 357338
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
When using multi-stage builds, we would like support cross-compilation.
Example is 2-stage build when the first stage is compiled for host while
the second stage is compiled for the target.
Normally, the second stage would be also used for compiling runtimes,
but that's not possible when cross-compiling, so we use the first stage
compiler instead. However, we still want to use the second stage paths.
To do so, we set the -resource-dir of the first stage compiler to point
to the resource directory of the second stage.
We also need compiler tools that support the target architecture. These
tools are not guaranteed to be present on the host, but in case of
multi-stage build, we can build these tools in the first stage.
Differential Revision: https://reviews.llvm.org/D54461
llvm-svn: 347025
This is necessary to make install-<target>-stripped work for
external projects such as runtimes.
Differential Revision: https://reviews.llvm.org/D49335
llvm-svn: 337115
This is needed when the external projects try to use other tools
besides just the compiler and the linker.
Differential Revision: https://reviews.llvm.org/D47833
llvm-svn: 334136
Summary:
Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if
passed in by user. This is the same way CLANG_TABLEGEN and
LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is
passed.
Differential Revision: https://reviews.llvm.org/D41806
llvm-svn: 323053
When cross-compiling, we cannot use the just built toolchain, instead
we need to use the host toolchain which we assume has a support for
targeting the selected target platform. We also need to pass the path
to the native version of llvm-config to external projects.
Differential Revision: https://reviews.llvm.org/D41678
llvm-svn: 322046
In my build environment (cmake 3.6.1 and gcc 4.8.5 on CentOS 7), having
an empty CMAKE_SYSROOT in the cache results in --sysroot="" being passed
to all compile commands, and then the compiler errors out because of the
empty sysroot. Only set CMAKE_SYSROOT if non-empty to avoid this.
Differential Revision: https://reviews.llvm.org/D40934
llvm-svn: 320183
Using comma can break in cases when we're passing flags that already
use comma as a separator.
Fixes PR35504.
Differential Revision: https://reviews.llvm.org/D40761
llvm-svn: 319719
CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP`
to enable stripping the installed binaries. LLVM's build system doesn't
expose this option to the `install-` targets, but it's useful in
conjunction with `install-distribution`.
Add a new function to create the install targets, which creates both the
regular install target and a second install target that strips during
installation. Change the creation of all installation targets to use
this new function. Stripping doesn't make a whole lot of sense for some
installation targets (e.g. the LLVM headers), but consistency doesn't
hurt.
I'll make other repositories (e.g. clang, compiler-rt) use this in a
follow-up, and then add an `install-distribution-stripped` target to
actually accomplish the end goal of creating a stripped distribution. I
don't want to do that step yet because the creation of that target would
depend on the presence of the `install-*-stripped` target for each
distribution component, and the distribution components from other
repositories will be missing that target right now.
Differential Revision: https://reviews.llvm.org/D40620
llvm-svn: 319480
LLVM runtimes rely on LLVM_HOST_TRIPLE being set in their builds
and tests so make sure it's being passed down.
Differential Revision: https://reviews.llvm.org/D40515
llvm-svn: 319109
Escaping ; in list arguments passed to ExternalProject_Add doesn't seem
to be working in newer versions of CMake (see
https://public.kitware.com/Bug/view.php?id=16137 for more details). Use
a custom LIST_SEPARATOR instead which is the officially supported way.
Differential Revision: https://reviews.llvm.org/D40232
llvm-svn: 319089
compile_commands.json file is very useful both for tooling and for
reproducible builds.
For files generated from recursive CMake invocation this information was
not previously generated.
Differential Review: https://reviews.llvm.org/D35219
llvm-svn: 308698
This changes adds support for building runtimes for multiple
different targets using LLVM runtimes directory.
The implementation follow the model used already by the builtins
build which already supports this option. To specify the runtimes
targets to be built, use the LLVM_RUNTIME_TARGETS variable, where
the valuae is the list of targets to build runtimes for. To pass
a per target variable to the runtimes build, you can set
RUNTIMES_<target>_<variable> where <variable> will be passed to the
runtimes build for <target>.
Each runtime target (except for the default one) will be installed
into lib/<target> subdirectory. Build targets will be suffixed with
the target name.
Differential Revision: https://reviews.llvm.org/D32816
llvm-svn: 307731
This change enables building builtins for multiple different targets
using LLVM runtimes directory.
To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS
variable, where the value is the list of targets. To pass a per target
variable to the builtin build, you can set BUILTINS_<target>_<variable>
where <variable> will be passed to the builtin build for <target>.
Differential Revision: https://reviews.llvm.org/D26652
llvm-svn: 289491
This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations.
The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad.
Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it.
llvm-svn: 280748
The subproject interface being used for runtime libraries expects that llvm-config is passed into the subproject for consumption. We currently do this for every subproject, so we should expect that all LLVM ExternalProjects depend on llvm-config for the time being.
Eventually I'd like to see the sub-projects using LLVMConfig.cmake instead of the llvm-config binary, but that will take time to roll out.
llvm-svn: 279155
Summary:
There are a few LLVM projects that produce runtime libraries. Ideally
runtime libraries should be built differently than other projects,
specifically they should be built using the just-built toolchain.
There is support for building compiler-rt in this way from the clang
build. Moving this logic into the LLVM build is interesting because it
provides a simpler way to extend the just-built toolchain to include
LLD and the LLVM object file tools.
Once this functionality is better fleshed out and tested we’ll want to
encapsulate it in a module that can be used for clang standalone
builds, and we’ll want to make it the default way to build compiler-rt.
With this patch applied there is no immediate change in the build.
Moving compiler-rt out from llvm/projects into llvm/runtimes enables
the functionality.
This code has a few improvements over the method provided by
LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is
always invoked, so changes to compiler-rt source files will get built
properly, so this patch can be used for iterative development with
just-built tools.
This first patch only works with compiler-rt. Support for other
runtime projects will be coming in follow-up patches.
Reviewers: chandlerc, bogner
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20992
llvm-svn: 273620
This makes it so that when running 'ninja test-suite' from the top-level LLVM ninja build it *always* re-runs the ninja command in the test-suite directory.
This mechanism is required because the top-level ninja file doesn't have a view into the subdirectory dependency tree, so it can't know what, if anything, needs to be rebuilt.
llvm-svn: 265863
When passing around CMake arguments as lists of arguments any arguments containing lists need to have their semi-colons escaped otherwise CMake will split the arguments in the middle.
llvm-svn: 253719
Petr Hosek