[CMake] Quote variables where "TARGET" may be a value

In CMake, "TARGET" is a special keyword. But it's also an LLVM component, which
means downstreams may request "target" or "TARGET" from CMake. Q

[CMake] Quote variables where "TARGET" may be a value

In CMake, "TARGET" is a special keyword. But it's also an LLVM component, which
means downstreams may request "target" or "TARGET" from CMake. Quote such input
so "TARGET" is interpreted as a string rather than a keyword.

This is a followup to 75a0502fe0053c72b57b61143a55600814d931fd (D150884).

Fixes Meson's test suite and an issue which manifested identically to #61436
but appears to have been a slightly different problem.

Bug: https://github.com/mesonbuild/meson/issues/11642
Bug: https://github.com/llvm/llvm-project/issues/61436

Reviewed By: tstellar

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

show more ...

[CMake] Set compatibility policy for lists in LLVM-Config.cmake.

Fixes "dependent projects fail to build with cmake 3.25 and llvm 16-rc4".

When building [latest `iovisor/bcc`](https://github.com/io

[CMake] Set compatibility policy for lists in LLVM-Config.cmake.

Fixes "dependent projects fail to build with cmake 3.25 and llvm 16-rc4".

When building [latest `iovisor/bcc`](https://github.com/iovisor/bcc/commit/1ea0390725391e76256af6a4d0eb857816e6290f), `cmake` complains about a change in the behavior of operator `IN_LIST`:
```console
CMake Warning (dev) at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake
--help-policy CMP0057" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.

IN_LIST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
src/cc/CMakeLists.txt:132 (include)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Error at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
if given arguments:

"engine" "IN_LIST" "link_components"

Unknown arguments specified
Call Stack (most recent call first):
cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
src/cc/CMakeLists.txt:132 (include)
```

This patch addresses this issue by setting the aforementioned policy in `LLVM-Config.cmake`.

Reviewed By: mgorny, thesamesam

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

Closes: https://github.com/llvm/llvm-project/issues/61436

show more ...

[CMake] Support undefined LLVM_NATIVE_ARCH in llvm_map_components_to_libnames().

https://reviews.llvm.org/D142405 made this function relying on the
LLVM_NATIVE_ARCH be defined, which is not necessar

[CMake] Support undefined LLVM_NATIVE_ARCH in llvm_map_components_to_libnames().

https://reviews.llvm.org/D142405 made this function relying on the
LLVM_NATIVE_ARCH be defined, which is not necessarily the case for
third-party projects that include LLVM as their part.

Reviewed By: beanz

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

show more ...

[CMake] Replace list(FIND) by if(IN_LIST) where index isn't used

If we don't use the index otherwise, if(IN_LIST) is more readable and
doesn't clutter the local scope with index variables.

This was

[CMake] Replace list(FIND) by if(IN_LIST) where index isn't used

If we don't use the index otherwise, if(IN_LIST) is more readable and
doesn't clutter the local scope with index variables.

This was pointed out by @beanz in D96670.

Reviewed By: beanz

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

show more ...

[CMake] Look up target subcomponents in LLVM_AVAILABLE_LIBS

In an installation using the all-contained libLLVM.so, individual
components are not available as targets, so we have to look them up in
L

[CMake] Look up target subcomponents in LLVM_AVAILABLE_LIBS

In an installation using the all-contained libLLVM.so, individual
components are not available as targets, so we have to look them up in
LLVM_AVAILABLE_LIBS just like llvm_map_components_to_libnames does it.
Here I don't think we need the capitalized names though because we know
the right capitalization. But I might be wrong.

This is required by dragonffi, who call llvm_map_components_to_libnames
on a list containing ${LLVM_NATIVE_ARCH}. Downstream bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1180748.

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

show more ...

[MCA] Moving the target specific CustomBehaviour impl. from /tools/llvm-mca/ to /lib/Target/.

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

[ASTMatchers] Fix build when no targets are enabled

This makes sense to do when building only tools like clang-tidy for
example.

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

llvmbuildectomy - compatibility with ocaml bindings

Use exact component name in add_ocaml_library.
Make expand_topologically compatible with new architecture.
Fix quoting in is_llvm_target_library.

llvmbuildectomy - compatibility with ocaml bindings

Use exact component name in add_ocaml_library.
Make expand_topologically compatible with new architecture.
Fix quoting in is_llvm_target_library.
Fix LLVMipo component name.
Write release note.

show more ...

llvmbuildectomy - replace llvm-build by plain cmake

No longer rely on an external tool to build the llvm component layout.

Instead, leverage the existing `add_llvm_componentlibrary` cmake function

llvmbuildectomy - replace llvm-build by plain cmake

No longer rely on an external tool to build the llvm component layout.

Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.

These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.

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

show more ...

Remove AllTargetsAsmPrinters

It's been an empty target since r360498 and friends
(`git log --grep='Move InstPrinter files to MCTargetDesc.' llvm/lib/Target`),
but due to hwo the way these targets ar

Remove AllTargetsAsmPrinters

It's been an empty target since r360498 and friends
(`git log --grep='Move InstPrinter files to MCTargetDesc.' llvm/lib/Target`),
but due to hwo the way these targets are structured it was silently
an empty target without anyone noticing.

No behavior change.

show more ...

[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"

Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM

[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"

Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so. Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:

1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so. This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.

With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.

2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set. This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.

I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:

- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON

Reviewers: beanz, smeenai, compnerd, phosek

Reviewed By: beanz

Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits

Tags: #llvm

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

show more ...

Fix use of add_llvm_tool in projects that build no targets

Projects that set LLVM_TARGETS_TO_BUILD to an empty list
can't use add_llvm_tool (and probably other macros).

Here's the error that this c

Fix use of add_llvm_tool in projects that build no targets

Projects that set LLVM_TARGETS_TO_BUILD to an empty list
can't use add_llvm_tool (and probably other macros).

Here's the error that this change fixes:

list sub-command REMOVE_ITEM requires two or more arguments.

https://reviews.llvm.org/D70167

Signed-off-by: Kevin Petit <kevin.petit@arm.com>

show more ...

[cmake] Remove confusing condition argument from else() NFC

Summary:
This makes it look like an elseif and also the variable referenced
in the condition was removed from this function in r366622.

R

[cmake] Remove confusing condition argument from else() NFC

Summary:
This makes it look like an elseif and also the variable referenced
in the condition was removed from this function in r366622.

Reviewers: dsanders, beanz, smeenai, compnerd, phosek

Reviewed By: beanz

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

show more ...

Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config

There were two main problems:
* The 'nativecodegen' pseudo-component was unconditionally adding
${native_tg

Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config

There were two main problems:
* The 'nativecodegen' pseudo-component was unconditionally adding
${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and
${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen
conditional too
* The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as
the expansion was to a library name and not a component. There doesn't seem to
be a list of available components anywhere so this has been fixed by moving the
expansion of 'all' back where it was before. This manifested in different ways
on different builders but it was the same root cause

llvm-svn: 366622

show more ...

Revert r366610 and r366612: Expand pseudo-components before embedding in llvm-config

Some targets are missing LLVMDemangle, one is adding the LLVM prefix twice, and two
are hitting the very error th

Revert r366610 and r366612: Expand pseudo-components before embedding in llvm-config

Some targets are missing LLVMDemangle, one is adding the LLVM prefix twice, and two
are hitting the very error this patch fixes for my target. Reverting while I work
through the reports.

llvm-svn: 366615

show more ...

Fix a latent bug discovered by r366610: nativecodegen includes X86CodeGen when X86 is not compiled

I believe this to have been a latent bug as the same expansion checks for the
existence of ${native

Fix a latent bug discovered by r366610: nativecodegen includes X86CodeGen when X86 is not compiled

I believe this to have been a latent bug as the same expansion checks for the
existence of ${native_tgt}Info and ${native_tgt}Desc and only adds them if
they were compiled but unconditionally adds ${native_tgt}CodeGen.

This should fix llvm-clang-x86_64-win-fast which builds ARM only on an X86 host and similar builders.

llvm-svn: 366612

show more ...

Expand pseudo-components before embedding in llvm-config

Summary:
If you use pseudo-targets like AllTargetsCodeGens in LLVM_DYLIB_COMPONENTS
then a test will fail because `./bin/llvm-config --shared

Expand pseudo-components before embedding in llvm-config

Summary:
If you use pseudo-targets like AllTargetsCodeGens in LLVM_DYLIB_COMPONENTS
then a test will fail because `./bin/llvm-config --shared-mode` can't
handle these targets. We can fix this by expanding them before embedding
the string into llvm-config

Reviewers: bogner

Reviewed By: bogner

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

llvm-svn: 366610

show more ...

Fix BUILD_SHARED_LIBS builds after r361567

Also fixed a comment I noticed while debugging this build

llvm-svn: 361591

Break false dependencies on target libraries

Summary:
For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with
some combination of AllTargets* so that they depend on specific compo

Break false dependencies on target libraries

Summary:
For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with
some combination of AllTargets* so that they depend on specific components
of a target backend rather than all of it. The overall effect of this is
that, for example, tools like opt no longer falsely depend on the
disassembler, while tools like llvm-ar no longer depend on the code
generator.

There's a couple quirks to point out here:
* AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil
seem to need it which I was surprised by.
* llvm-xray linked to all the backends but doesn't seem to need any of them.
It builds and passes the tests so that seems to be correct.
* I left gold out as it's not built when binutils is not available so I'm
unable to test it

Reviewers: bogner, JDevlieghere

Reviewed By: bogner

Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits

Tags: #llvm

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

llvm-svn: 361567

show more ...

[CMake] Avoid REVERSE on unset variable

If required_libs happens to remain unset, CMake would fail with:

list sub-command REVERSE requires list to be present.

Fix by ensuring we do not attempt t

[CMake] Avoid REVERSE on unset variable

If required_libs happens to remain unset, CMake would fail with:

list sub-command REVERSE requires list to be present.

Fix by ensuring we do not attempt to reverse an unset variable.

Reported by Tu Vuong.

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

llvm-svn: 343088

show more ...

[cmake] fix a typo in llvm_config macro

Summary:
The macro parses out the USE_SHARED option out of the argument list, but
then ignores it and accesses the variable with the same name instead. It
see

[cmake] fix a typo in llvm_config macro

Summary:
The macro parses out the USE_SHARED option out of the argument list, but
then ignores it and accesses the variable with the same name instead. It
seems the intention here was to check the argument value.

Technically, this is NFC, because the only in-tree usage
(add_llvm_executable) of USE_SHARED sets both the variable and the
argument when calling llvm_config, but it makes the usage of this macro
for out-of-tree users more sensible.

Reviewers: mgorny, beanz

Reviewed By: mgorny

Subscribers: foutrelis, llvm-commits

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

llvm-svn: 334082

show more ...

[CMake] Use PRIVATE in target_link_libraries for executables

We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Depen

[CMake] Use PRIVATE in target_link_libraries for executables

We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.

Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.

Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).

Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.

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

llvm-svn: 319840

show more ...

[cmake] Modernize some conditionals. NFC

The "x${...}" form was a workaround for CMake versions prior to 3.1,
where the if command would interpret arguments as variables even when
quoted [1]. We can

[cmake] Modernize some conditionals. NFC

The "x${...}" form was a workaround for CMake versions prior to 3.1,
where the if command would interpret arguments as variables even when
quoted [1]. We can drop the workaround now that our minimum CMake
version is 3.4.

[1] https://cmake.org/cmake/help/v3.1/policy/CMP0054.html

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

llvm-svn: 319723

show more ...

[CMake][LLVM] Remove duplicated library mask. Broken clang linking against clangShared

Summary:
The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LL

[CMake][LLVM] Remove duplicated library mask. Broken clang linking against clangShared

Summary:
The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LLVMARMInfo, LLVMAArch4Info, etc appearing twice in `extract_symbols.py` command line while building `clangShared`. `Extract_symbols.py` does not work well in such a case and completely ignores the symbols from the duplicated libraries. Thus, the LLVM(...)Info symbols do not get exported from `clangShared` and linking clang against it fails with unresolved dependencies.

Seems to be a mere copy-paste mistake.

Reviewers: beanz, chapuni

Reviewed By: chapuni

Subscribers: chapuni, aemerson, mgorny, kristof.beyls, llvm-commits, asl

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

llvm-svn: 310590

show more ...

[CMake] Fix `is_llvm_target_library` and support out-of-order components

Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependenci

[CMake] Fix `is_llvm_target_library` and support out-of-order components

Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies.

Reviewers: mgorny, chapuni, bryant

Subscribers: llvm-commits, jgosnell

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

llvm-svn: 294514

show more ...