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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279155 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276829 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276667 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275007 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274546 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274351 91177308-0d34-0410-b5e6-96231b3b80d8
This flag is only effective in builds with debug info and modules.
The default is On for Darwin only.
rdar://problem/27019000
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274244 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274242 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274196 91177308-0d34-0410-b5e6-96231b3b80d8
This matches more closely the rest of the variables in LLVMConfig.cmake which
shed the _CONFIG_ part of their names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274175 91177308-0d34-0410-b5e6-96231b3b80d8
This is just a small step in the direction of making LLVMConfig.cmake a complete
replacement for llvm-config.
For those unfamiliar, llvm-config --build-mode prints out CMAKE_BUILD_TYPE. Thus
as one can imagine, LLVM_BUILD_TYPE is @CMAKE_BUILD_TYPE@.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273782 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273620 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Nitesh Jain.
Summary: On some target like MIPS32 we need to explicitly link atomic library for 64 bit atomic operations. This module then can be used in LLDB (http://reviews.llvm.org/D20464) or Libcxx (http://reviews.llvm.org/D16613) for explicitly link to atomic library.
Reviewers: chandlerc, beanz
Differential: reviews.llvm.org/D20896
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273534 91177308-0d34-0410-b5e6-96231b3b80d8
LLVMConfig.cmake needs to set LLVM_BINARY_DIR differently based on whether or not it is the build directory or the install directory. The build directory just needs to set the value from the configuration, the install directory needs to set it to the install prefix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273479 91177308-0d34-0410-b5e6-96231b3b80d8
After r273302 LLVM_SYSTEM_LIBS may have entries that already have
-l prefix and we need to deal with that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273333 91177308-0d34-0410-b5e6-96231b3b80d8
All the ExternalProject features in use here are supported by CMake 3.4.3, so we don't need these version checks anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272327 91177308-0d34-0410-b5e6-96231b3b80d8
This is the more-correct fix to out-of-tree building. AddLLVM.cmake relies on this variable being set, so we should make sure it is set in LLVMConfig.cmake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272279 91177308-0d34-0410-b5e6-96231b3b80d8
cmake 3.4 introduced LIST_DIRECTORIES to glob recurse, which can be
used to simplify this code greatly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272217 91177308-0d34-0410-b5e6-96231b3b80d8
This was called out on the list a long time ago and just got pointed out to me again. Need to fix it before I forget.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272201 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a new option LLVM_TOOLS_INSTALL_DIR which allows customizing the location executables and symlinks get installed to. This adds the functionality provided by autoconf's --bindir flag.
This patch is based on patches from and collaboration with Tony Kelman, and replaces http://reviews.llvm.org/D20934.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272200 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows customizing the location executables and symlinks get installed to,
as with --bindir in autotools.
Reviewers: loladiro, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20934
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272031 91177308-0d34-0410-b5e6-96231b3b80d8
With CMP0056, try_compile() uses also CMAKE_EXE_LINKER_FLAG.
It caused mismatch between CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS, to fail to examine CXX_SUPPORTS_CXX11 with -m32.
FYI, before this, try_compile() tries without -m32 regardless of LLVM_BUILD_32_BITS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271871 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently cmake differentiates between Clang and AppleClang, and we
fail to color our diagnostics if you have the latter. Fix that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271442 91177308-0d34-0410-b5e6-96231b3b80d8
The problem with plugins on Windows is that when building a plugin DLL it needs
to explicitly link against something (an exe or DLL) if it uses symbols from
that thing, and that thing must explicitly export those symbols. Also there's a
limit of 65535 symbols that can be exported. This means that currently plugins
only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with
MSVC.
This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled
automatically exports from all LLVM tools the symbols that a plugin could want
to use so that a plugin can link against a tool directly. Plugins can specify
what tool they link against by using PLUGIN_TOOL argument to llvm_add_library.
The option can also be enabled on Linux, though there all it should do is
restrict the set of symbols that are exported as by default all symbols are
exported.
This option is currently OFF by default, as while I've verified that it works
with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no
idea what will happen on OSX. Also unfortunately we can't turn on
LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be
loaded by both bugpoint.exe and opt.exe which is incompatible with this
approach. Also currently clang plugins don't work with this approach, which
will be fixed in future patches.
Differential Revision: http://reviews.llvm.org/D18826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270839 91177308-0d34-0410-b5e6-96231b3b80d8
This should actually address PR27855. This results in adding references to the system libs inside generated dylibs so that they get correctly pulled in when linking against the dylib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270723 91177308-0d34-0410-b5e6-96231b3b80d8
Compiler-RT needs LLVM_LIBRARY_DIR, LLVM_BINARY_DIR.
Setting these in LLVMConfig.cmake will allow Compiler-RT to not need to run llvm-config as long as the LLVMConfig.cmake module is in the CMake module path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269104 91177308-0d34-0410-b5e6-96231b3b80d8
Currently our cmake generates targets like check-llvm-unit and
check-llvm-transforms-loopunroll-x86, but not check-llvm-transforms or
check-llvm-transforms-adce. This is because the search for test suites
only lists the ones with a custom lit.cfg or lit.local.cfg.
Instead, we can do something a little smarter - any directory under
test that isn't called Inputs or inside a directory called Inputs is a
test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268806 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.
The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.
With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.
See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html
Reviewers: bogner, silvas, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19892
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268670 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268050 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: For Incremental LTO, we need to make sure that an old
cache entry is not used when incrementally re-linking with a new
libLTO.
Adding a global LLVM_REVISION in llvm-config.h would for to
rebuild/relink the world for every "git pull"/"svn update".
So instead only libLTO is made dependent on the VCS and will
be rebuilt (and the dependent binaries relinked, i.e. as of
today: libLTO.dylib and llvm-lto).
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18987
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266523 91177308-0d34-0410-b5e6-96231b3b80d8
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266515 91177308-0d34-0410-b5e6-96231b3b80d8
