Make LIT_COMMAND configurable, use source tree only when actually
available and extend the default search to other common executable names
'lit.py' and 'lit', in order to increase uniformity between all LLVM
projects and support using installed lit.
Changing the conditional used to determine whether in-tree or external
lit is being used covers the case when LLVM_MAIN_SRC_DIR is defined but
does not exist (anymore). In this case, the functions falls back to
looking for installed lit rather than attempting to use a non-existing
path. The same conditional is used in clang already.
Making LIT_COMMAND a cache variable in case the source tree variant is
used serves two purposes. Firstly, it increases uniformity between
the two branches since find_program() implicitly makes LIT_COMMAND
a cache variable. Secondly, it allows overriding the lit executable used
to run the tests when the LLVM source tree is provided. Gentoo is
planning to use this to use installed (and byte-compiled) lit instead of
re-compiling it in every LLVM project.
Extending default search is meant to increase uniformity between
different LLVM projects. The 'lit.py' name is already used by a few of
them, and 'lit' is the name used by utils/lit/setup.py when installing.
Differential Revision: https://reviews.llvm.org/D25076
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283247 91177308-0d34-0410-b5e6-96231b3b80d8
Reintroduce versioning of shared libraries via SOVERSION, addressing
the issues with the previous design, since Gentoo is relying
on shared-split install of LLVM. The SOVERSIONs were originally
introduced in r229720 for all libraries, and removed in r252093 in favor
of custom SONAME. As far as I understand, the major concern with the old
versioning was that the used versions were incompatible with ldconfig.
Having considered that, this commit introduce SOVERSIONS with the
following considerations:
1. SOVERSIONs are formed of major & minor version concatenated -- i.e.
for 4.0 its .so.40. This matches the common practice where the first
version number indicates ABI breakage, and therefore fixes the issues
with ldconfig. Additionally, VERSION with the remaining verion
components appended is used, however this is not strictly necessary.
2. The versioning is only applied to libraries with no explicit SONAME
specified -- i.e. it won't apply to libLLVM but only to the split
libraries. It will also apply to libraries installed by the subprojects.
3. The versioning is only done on *nix systems, Darwin excluded. This
matches the current use of SONAME.
Differential Revision: https://reviews.llvm.org/D24757
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283189 91177308-0d34-0410-b5e6-96231b3b80d8
Revert the change in r283029 (and the fixup in r283033) due to buildbot
breakage. The fixup is ineffective for the bots that do not force clean
build since the wrong value is already cached in CMakeCache.txt.
Reverting it should result in the cache variable being removed
and therefore it should be possible to re-introduce it after all
buildbots build this revision.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283036 91177308-0d34-0410-b5e6-96231b3b80d8
Make LIT_COMMAND configurable, use source tree only when actually
available and extend the default search to other common executable names
'lit.py' and 'lit', in order to increase uniformity between all LLVM
projects and support using installed lit.
Changing the conditional used to determine whether in-tree or external
lit is being used covers the case when LLVM_MAIN_SRC_DIR is defined but
does not exist (anymore). In this case, the functions falls back to
looking for installed lit rather than attempting to use a non-existing
path. The same conditional is used in clang already.
Making LIT_COMMAND a cache variable in case the source tree variant is
used serves two purposes. Firstly, it increases uniformity between
the two branches since find_program() implicitly makes LIT_COMMAND
a cache variable. Secondly, it allows overriding the lit executable used
to run the tests when the LLVM source tree is provided. Gentoo is
planning to use this to use installed (and byte-compiled) lit instead of
re-compiling it in every LLVM project.
Extending default search is meant to increase uniformity between
different LLVM projects. The 'lit.py' name is already used by a few of
them, and 'lit' is the name used by utils/lit/setup.py when installing.
Differential Revision: https://reviews.llvm.org/D25076
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283029 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282844 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281788 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281763 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281085 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
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 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
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
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
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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265041 91177308-0d34-0410-b5e6-96231b3b80d8
This adds llvm_add_implicit_projects which takes a project name and is wrapped by add_llvm_implicit_projects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262948 91177308-0d34-0410-b5e6-96231b3b80d8
When we build LLVM with externalized debug info, all debugging and
symbolication related data is extracted into dSYM files prior to
stripping. As such, there is no need to preserve local symbols in LLVM
binaries after dSYM creation.
This shrinks libLLVM.dylib from 58MB to 55MB on my system.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258566 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a re-commit of r257003, which was reverted,
along with the fixes from http://reviews.llvm.org/D15986.
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15986
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258283 91177308-0d34-0410-b5e6-96231b3b80d8
With this, one can build a lib from the objects of other libs:
set(SOURCES
$<TARGET_OBJECTS:obj.clingInterpreter>
$<TARGET_OBJECTS:obj.clingMetaProcessor>
$<TARGET_OBJECTS:obj.clingUtils>
)
Reviewed by Chris Bieneman - thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257459 91177308-0d34-0410-b5e6-96231b3b80d8
This revision breaks llvm-config if you set
BUILD_SHARED_LIBS=on in a CMake build. Backing
out until the fix is ready to land.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257457 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15033
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257003 91177308-0d34-0410-b5e6-96231b3b80d8
One of the earlier patches updated the cmake rule to install the
runtime dlls in INSTALL_DIR/lib which is not correct. This patch
updates the rule to install CMake's RUNTIME in bin directory
Differential Revision: http://reviews.llvm.org/D15505
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255781 91177308-0d34-0410-b5e6-96231b3b80d8
If you externalize debug info for unit tests the test runner finds the mach-o inside the dsym bundle and tries to execute it as a test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255056 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.
Reviewers: bogner, friss
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15133
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254627 91177308-0d34-0410-b5e6-96231b3b80d8
This is required to support multilib install targets, and addresses a regression introduced in r252093.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252749 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Move handling of the SONAME option from add_llvm_library
to llvm_add_library, so that it can be used in sub-projects.
In particular, this makes it possible to have consistently
named shared libraries for LLVM, Clang and LLDB.
Also, base the SONAME and symlinks on the output name
by extracting the OUTPUT_NAME property, rather than assuming
it is the same as the target name.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14539
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252669 91177308-0d34-0410-b5e6-96231b3b80d8
When configuring various llvm projects that use AddLLVM.cmake, this warning is
emitted many times, flooding the screen:
Policy CMP0007 is not set: list command no longer ignores empty elements.
The fix is removing an extra semicolon.
Differential Revision: http://reviews.llvm.org/D14339
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252628 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change makes the CMake build system generate libraries for Linux and Darwin matching the makefile build system.
Linux libraries follow the pattern lib${name}.${MAJOR}.${MINOR}.so so that ldconfig won't pick it up incorrectly.
Darwin libraries are not versioned.
Note: On linux the non-versioned symlink is generated at install-time not build time. I plan to fix that eventually, but I expect that is good enough for the purposes of fixing this bug.
Reviewers: loladiro, tstellarAMD
Subscribers: axw, llvm-commits
Differential Revision: http://reviews.llvm.org/D13841
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252093 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This prints NO if LLVM was built with -fno-rtti or an equivalent flag
and YES otherwise. The reasons to add -has-rtti rather than adding -fno-rtti
to --cxxflags are:
1. Building LLVM with -fno-rtti does not always mean that client
applications need this flag.
2. Some compilers have a different flag for disabling rtti, and the
compiler being used to build LLVM may not be the compiler being used to
build the application.
Reviewers: echristo, chandlerc, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11849
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252075 91177308-0d34-0410-b5e6-96231b3b80d8
Michal Gorny