If this is set, %INCLUDE% must contain ".../DIA SDK/include"
and %LIB% must contain ".../DIA SKD/lib/amd64" (assuming you're doing a
64-bit build).
llvm-svn: 359195
Since the symlinks list for llvm-symbolizer is now never empty,
the :symlinks target no longer needs an explicit dep on :llvm-symbolizer
-- there will be at least one dep on a symlink, and each symlink depends
on :llvm-symbolizer already.
Since llvm-symbolizer:symlinks now produces symlinks that check-llvm
uses, make llvm/test depend on the symlink target.
llvm-svn: 358861
ClangdLSPServer and clangd unittests now include Features.inc so we
need to append the target_gen_dir that contains it to their
include_dirs. To do so, we use a public config that's applied to
any target that depends on the features one.
Differential Revision: https://reviews.llvm.org/D60919
llvm-svn: 358837
Summary:
Previously, write_cmake_config.py would raise an error while printing
the error, because `leftovers` in "'\n'.join(leftovers)" is a tuple.
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60766
llvm-svn: 358557
This change also introduces the clang_enable_per_target_runtime_dir
to enable the use of per-target runtime directory layout which is the
equivalent of LLVM_ENABLE_PER_TARGET_RUNTIME_DIR CMake option.
Differential Revision: https://reviews.llvm.org/D60332
llvm-svn: 357850
This is support for building compiler-rt builtins, The library build
should be complete for a subset of supported platforms, but not all
CMake options have been replicated in GN.
We always use the just built compiler to build all the runtimes, which
is equivalent to the CMake runtimes build. This simplifies the build
configuration because we don't need to support arbitrary host compiler
and can always assume the latest Clang. With GN's toolchain support,
this is significantly more efficient than the CMake runtimes build.
Differential Revision: https://reviews.llvm.org/D60331
llvm-svn: 357821
We should be always rebasing paths against root_build_dir which is
the directory where scripts are run from, not root_out_dir which is
the current toolchain directory. The latter can result in invalid
paths when the action is being used from a non-default toolchain.
Differential Revision: https://reviews.llvm.org/D60330
llvm-svn: 357798
This allows it to be disabled for targets that need exceptions
like libunwind, libc++abi and libc++.
Differential Revision: https://reviews.llvm.org/D60328
llvm-svn: 357797
Summary:
This avoids the need to talk about lib.exe or llvm-lib.exe and it does
the right thing with LLD.
Reviewers: thakis
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60155
llvm-svn: 357660
None of check-clang-tools's tests run this, but the CMake
check-clang-tools depends on the binary, so add it for consistency.
Differential Revision: https://reviews.llvm.org/D60222
llvm-svn: 357624
This is a bit of a larger change since this is the first (and as far as
I can tell only) place where the LLVM build produces macOS framework
bundles.
GN has some built-in support for this, so use that.
`gn help create_bundle` has a terse description (but it's a bit
outdated: `deps` must be `public_deps` and the conditionals in the
example in the help aren't quite right on non-iOS).
We need a new 'copy_bundle_data' tool, and since we copy the clangd.xpc
bundle as bundle_data into ClangdXPC.framework it needs to be able to
handle directories in addition to files.
GN also insists we have a compile_xcassets tool even though it's not
used. I just made that run `false`.
Despite GN's support for bundles, we still need to manually create the
expected symlink structure in the .framework bundle. Since this code
never runs on Windows, it's safe to create the symlinks before the
symlink targets exist, so we can just make the bundle depend on the
steps that create the symlinks. For this to work, change the symlink
script to create the symlink's containing directory if it doesn't yet
exist.
I locally verified that CMake and GN build create the same bundle
structure. (I noticed that both builds set LC_ID_DYLIB to the pre-copy
libClangdXPCLib.dylib name, but that seems to not cause any issues and
it happens in the CMake build too.)
(Also add an error message to clangd-xpc-test-client for when loading
the dylib fails – this was useful while locally debugging this.)
Differential Revision: https://reviews.llvm.org/D60130
llvm-svn: 357574
Nico Weber