Add a OCAML_INSTALL_PATH variable that can be used to control
the install path for OCaml libraries. The new variable defaults to
${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from
the OCaml compiler. Install libraries into "llvm" subdirectory.
This fixes two issues:
1. OCaml library directories differ between systems, and 'lib/ocaml' is
incorrect e.g. on amd64 Gentoo where OCaml is installed
in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml
compiler using 'ocamlc -where' (which is already used to set
OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages.
2. The top-level directory is reserved for the standard library, and has
precedence over local directory in search path. As a result, OCaml
preferred the files installed along with previous LLVM version over the
source tree when building a new version, resulting in two versions being
mixed during the build. The new layout is used commonly by other OCaml
packages, and findlib is able to find the LLVM libraries successfully.
Bug: https://bugs.gentoo.org/559134
Bug: https://bugs.gentoo.org/559624
Differential Revision: https://reviews.llvm.org/D24354
llvm-svn: 282895
When LLVM_INSTALL_TOOLCHAIN_ONLY is used and LLVM_TOOLCHAIN_TOOLS
contains a tool which is a symlink, it would be ignored. This already
worked before but got broken in r282510.
Differential Revision: https://reviews.llvm.org/D25067
llvm-svn: 282844
Summary:
The previous output was confusing as it would output "Taget triple:
x86_64-unknown-linux-gnu" even when LLVM_HOST_TRIPLE or
LLVM_DEFAULT_TARGET_TRIPLE were set on the CMake command line
Patch by: Alex Richardson!
Reviewers: beanz
Subscribers: Eugene.Zelenko
Differential Revision: https://reviews.llvm.org/D17067
llvm-svn: 282516
This supports creating symlinks to tools in different directories than
the tool is built to. This is useful for the LLDB framework build which
I’m sending patches for shortly.
llvm-svn: 281788
Summary:
When LLVM_LINK_LLVM_DYLIB is set, the libLLVM shared
library needs to be installed in the toolchain. Without
this chanage LLVM_INSTALL_TOOLCHAIN_ONLY combined with
LLVM_LINK_LLVM_DYLIB results in a broken install.
Patch by Sam Clegg
Differential Revision: https://reviews.llvm.org/D24676
llvm-svn: 281763
Previously, gtest/gtest_main were not exported via cmake. The intention here was
to ensure that users whom are linking against the LLVM install tree would not
get the gtest/gtest_main targets. This prevents downstream projects that link
against the LLVM build tree (i.e. Swift) from getting this dependency
information in their cmake builds. Without such dependency information, linker
issues can result on linux due to LLVMSupport being put before gtest on the
linker command line.
This commit preserves behavior that we want for the install tree, while adding
support for the build tree by:
1. The special casing for gtest/gtest_main in the add_llvm_library code is
removed in favor of a flag called "BUILDTREE_ONLY". If this is set, then the
library is communicating that it is only meant to be exported into the build
tree and is not meant to be installed or exported via the install tree. This
part is just a tweak to remove the special case, the underlying code is the
same.
2. The cmake code that exports cmake targets for the build tree has special code
to import an additional targets file called
LLVMBuildTreeOnlyExports.cmake. Additionally the extra targets are added to the
LLVMConfig.cmake's LLVM_EXPORTED_TARGETS variable. In contrast, the
"installation" cmake file uses the normal LLVM_EXPORTS_TARGETS as before and
does not include the extra exports file. This is implemented by
defining/undefining variables when performing a configure of the build/install
tree LLVMConfig.cmake files.
llvm-svn: 281085
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
This adds a copy of the demangler in libcxxabi.
The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.
The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:
No constexpr.
No alignas
On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi
My current plan is:
Commit something like this
Change lld to use it
Change lldb to use it as the fallback
Add a few #ifdefs so that exactly the same file can be used in
libcxxabi to export abi::__cxa_demangle.
Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.
llvm-svn: 280732
That is, add build system support for building the OCaml bindings
against preinstalled LLVM libraries. This is important for package
managers such as OPAM, because OCaml libraries need to be built
against a specific OCaml compiler installation.
llvm-svn: 280642
This is a partial revert of r280013. Brad King pointed out these variable names are matching CMake conventions, so we should preserve them.
I've also added a direct mapping of the LLVM_*_DIR variables which we need to make projects support building in and out of tree.
llvm-svn: 280380
With the runtimes build we're trying to use LLVMConfig.cmake as a way of providing LLVM_* variables that are needed to behave as if the project is building in tree. To make this work we need to rename two variables by dropping the "S" from the end. This makes the variables match the in-tree names.
This renames:
LLVM_INCLUDE_DIRS -> LLVM_INCLUDE_DIR
LLVM_LIBRARY_DIRS -> LLVM_LIBRARY_DIR
The versions ending in S are not used in-tree anywhere. This also cleans up LLVM_LIBRARY_DIR being set to the same value with and without the "S".
llvm-svn: 280013
Summary:
Install CheckAtomic.cmake along with other LLVM modules, therefore making it possible for other projects to use it. This file is needed for LLDB to be built standalone, and installing it was suggested in https://reviews.llvm.org/D23881.
Patch by: Michał Górny
Reviewers: krytarowski, zturner, eugenis, jyknight, labath, beanz
Subscribers: beanz, llvm-commits
Differential Revision: https://reviews.llvm.org/D23887
llvm-svn: 279777
Summary: Asan fails to UnsetAlternateSignalStack if it set by Unix/Signals.inc
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23864
llvm-svn: 279717
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:
To build llgo, you must currently ensure that llgo
is in the tools/llgo directory, due to a hard-coded
path in llvm-go.
To support the use of LLVM_EXTERNAL_LLGO_SOURCE_DIR,
we introduce a flag to llvm-go that enables the
caller to specify the paths to symlink in the
temporary $GOPATH.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D21634
llvm-svn: 276829
Given similar reasons from r276710, ld64 scrubs DYLD_* environment if
called from the shim executable /usr/bin/ld.
Add support for finding ld64 via xcrun.
This is needed in order to get LIT to have the full path to the ld4
executable.
Differential Revision: https://reviews.llvm.org/D22791
rdar://problem/24300926
llvm-svn: 276781
With in-tree builds we can get Output directories scattered among our
tests. Recursing into those to find tests doesn't make sense.
Thanks to nlewycky for noticing this!
llvm-svn: 276667
This makes sure that space is actually available. With this change
running lld on a full file system causes it to exit with
failed to open foo: No space left on device
instead of crashing with a sigbus.
llvm-svn: 276017
This option is the equivalent option to LLVM_BUILD_TOOLS but for executables
created via add_llvm_utility.
This is a useful tool for improving compile time in situations where LLVM is
used as a library and no testing tools are needed.
It follows the exact same implemention model as LLVM_BUILD_TOOLS.
Since the option is by default set to on, no behavior is changed unless one sets
it from the command line to be false.
llvm-svn: 275007
export_executable_symbols looks though the link libraries of the executable in
order to figure out transitive dependencies, but in doing so it assumes that
all link libraries are also targets. This is not true as of r273302, so adjust
it to check if they actually are targets.
llvm-svn: 274546
Previously out-of-tree passes could detect if LLVM was built with
LLVM_BUILD_32_BITS by looking for -m32 in LLVM_DEFINITIONS, but as of r271871
it no longer appears there. Resolve this by instead emitting LLVM_BUILD_32_BITS
in LLVMConfig so it can be checked for directly.
Differential Revision: http://reviews.llvm.org/D21434
llvm-svn: 274351
This reverts commit 3db82f646a0890eb7664d0351b5a3c79622e8bef.
Vassil already fixed this and I mechanically undid his fix without looking
too close at what I'm actually doing. Need more coffee.
llvm-svn: 274242
This fixes a typo introduced in r274196.
Thanks to Vassil Vassilev for noticing!
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274240
On Darwin it is currently impossible to build LLVM with modules
because the Darwin system module map is not compatible with
-fmodules-local-submodule-visibility at this point in time. This
patch makes the flag optional and off by default on Darwin so it
becomes possible to build LLVM with modules again.
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274196
