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.
llvm-svn: 272279
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.
llvm-svn: 272200
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
llvm-svn: 272031
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.
llvm-svn: 271871
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
llvm-svn: 270839
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.
llvm-svn: 270723
to llvm-objdump. This section is created with -fembed-bitcode option.
This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!
rdar://26202242
llvm-svn: 270491
the C standard library implementation in use.
This works around a glibc bug in the backtrace() function where it fails to
produce a backtrace on x86_64 if libgcc / libunwind is statically linked.
llvm-svn: 270276
- glibc is dynamically linked, and
- libgcc_s is unavailable (for instance, another library is being used to
provide the compiler runtime or libgcc is statically linked), and
- the target is x86_64.
If we run backtrace() and it fails to find any stack frames, try using
_Unwind_Backtrace instead if available.
llvm-svn: 269992
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.
llvm-svn: 269104
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.
llvm-svn: 268806
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
llvm-svn: 268670
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
llvm-svn: 268050
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>
llvm-svn: 266523
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.
llvm-svn: 266515
1) We need to add this flag prior to adding any other, in case the user has
specified a -fmodule-cache-path= flag in their custom CXXFLAGS. Such a flag
causes -Werror builds to fail, and thus all config checks fail, until we add
the corresponding -fmodules flag. The modules selfhost bot does this, for
instance.
2) Delete module maps that were putting .cpp files into modules.
3) Enable -fmodules-local-submodule-visibility, to get proper module
visibility rules applied across submodules of the same module. Disable
-fmodules for C builds, since that flag is not available there.
llvm-svn: 266502
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
`sys/types.h` has a related define in `config.h.cmake`, but was never
checked for in CMake. Sync this.
Differential Revision: http://reviews.llvm.org/D18825
llvm-svn: 265648
For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting LLVM_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On.
llvm-svn: 265041
What we are really trying to do here is to figure out if we are using
the 2015 STL. Unfortunately, so far as I know the MSVC STL does not
define a version macro that we can check directly. Instead I wrote a
check to see if char16_t works.
llvm-svn: 264881
Add a missing include. This is important in the case HandleLLVMOptions is
included prior to the missing CheckCXXSourceCompiles or CheckCXXCompilerFlag
which includes CheckCXXSourceCompiles.
llvm-svn: 262949
Otherwise users get messages from CheckAtomic about missing libatomic
instead of a sensible message that says "use GCC 4.7 or newer".
I structured the change along the lines of HandleLLVMStdlib.cmake, so
that the standalone build of Clang still gets the compiler version
check.
Reviewers: beanz
Differential Revision: http://reviews.llvm.org/D17789
llvm-svn: 262491
This patch updates cmake build scripts to build on Haiku. It adds Haiku x86_64 to config.guess.
Please consider reviewing.
Pathc by Jérôme Duval.
llvm-svn: 262038
- Remove a comment that was clearly copy pasted from Android.cmake and
isn't relevant.
- Remove the toolchain's sensitivity to the environment. It's less
error prone to just allow users to set CMAKE_OSX_SYSROOT if they
want to use a custom SDK.
- Stop explicitly setting -mios-version-min to the default value. It
just adds needless complexity.
This makes building the native tablegen work for me even when SDKROOT
is set in the environment (or passed in as -DCMAKE_OSX_SYSROOT).
llvm-svn: 260763
Patch by Jack Howarth.
When linking to libLLVM, don't also link to the component
libraries that constitute libLLVM.
Differential Revision: http://reviews.llvm.org/D16945
llvm-svn: 260641
Very often in LLVM we have APIs that take a bitwidth and a uint64_t that
we pass immediates such as ~0U to. Consider APInt, Constant, and
MachineInstrBuilder::addImm. Fixing all uses of these APIs to manually
extend their arguments to uint64_t doesn't seem worth it.
llvm-svn: 260416
