This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators.
llvm-svn: 288679
The old implementation of add_llvm_tool_symlink could fail in odd ways when building out of tree. This version solves that problem by not using the LLVM_* variables, and instead reaeding the target's properties.
llvm-svn: 288632
Add an optional parameter to `llvm_install_symlink` which allows the symlink
installation to be placed into a specific component rather than the default
value.
llvm-svn: 288600
This fixes a regression introduced by r285714: we weren't setting the
rpath on LLVMgold.so correctly.
Spotted by mark@chromium.org!
Differential Revision: https://reviews.llvm.org/D27176
llvm-svn: 288076
When LLVM_DEPENDENCY_DEBUGGING=On we should apply the sandbox only on the target, not the directory. This is important for directories that create more than one target, or for nested directories.
llvm-svn: 287415
This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen.
Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency.
llvm-svn: 287207
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for LLVM's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.
llvm-svn: 286209
Summary:
Set _install_rpath to CMAKE_INSTALL_RPATH if it is defined, so that eventually
INSTALL_RPATH is set to CMAKE_INSTALL_RPATH.
The "if(NOT DEFINED CMAKE_INSTALL_RPATH)" was missing a corresponding else
clause.
This also cleans up the fix made in r285908.
Patch by Azharuddin Mohammed
Reviewers: john.brawn, sgundapa, beanz
Subscribers: chapuni, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26289
llvm-svn: 286184
This Makes sure we only export targets that we're distributing, since
cmake will fail to import the file otherwise due to missing targets.
llvm-svn: 286024
r285714 made it so that when CMAKE_INSTALL_RPATH is set _install_rpath is not
set, but that means INSTALL_RPATH gets set to an empty string which isn't what
we want. Fix this by setting INSTALL_RPATH only when _install_rpath is set.
llvm-svn: 285908
This patch was produced in conjunction with Michał Górny. It should resolve the issues that were trying to be solved by D25304.
This moves rpath handling into `llvm_add_library` and `add_llvm_executable` so that it is available to all projects using AddLLVM whether built in-tree or out-of-tree.
llvm-svn: 285714
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
llvm-svn: 283247
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
llvm-svn: 283189
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.
llvm-svn: 283036
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
llvm-svn: 283029
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
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
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
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 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
Otherwise it gets linked in by one of the dependencies of shared
libraries which may be too late and we end up with weird crashes in
std::call_once().
Differential Revision: http://reviews.llvm.org/D21478
llvm-svn: 273302
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
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
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
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
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
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
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.
llvm-svn: 258566
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
llvm-svn: 258283
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!
llvm-svn: 257459
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
llvm-svn: 257003
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
llvm-svn: 255781
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.
llvm-svn: 255056
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
llvm-svn: 254627
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
llvm-svn: 252669
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
llvm-svn: 252628
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
llvm-svn: 252093
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
llvm-svn: 252075
r250835 unintentionally discarded the optional parameter to the
add_llvm_external_project() macro that may point to a path when the said
path is different from ${name}. This should fix it by passing ${ARGN} on
to add_llvm_subdirectory(). The problem manifests itself with e.g.
add_llvm_external_project(clang-tools-extra extra) from
clang/tools/CMakeLists.txt
Patch by Luchesar V. Iliev.
llvm-svn: 251001
Summary:
This refactoring makes some of the code used to control including subdirectories parameterized so it can be re-used elsewhere.
Specifically I want to re-use this code in clang to be able to turn off specific tool subdirectories.
Reviewers: chapuni, filcab, bogner, Bigcheese
Subscribers: emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D13783
llvm-svn: 250835
In order to resolve PR25059, we're going to need to be able to generate symlinks to libraries manually, so I need this code to be reusable.
llvm-svn: 250573
When building a plugin against an installed LLVM toolchain using
add_llvm_loadable_module (in the documented manner) doesn't work as nothing sets
the *_OUTPUT_INTDIR variables causing an error when set_output_directory is
called. Making those arguments optional (causing the default output directory
to be used) fixes this.
Differential Revision: http://reviews.llvm.org/D13215
llvm-svn: 248911
Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining
the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to
use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used.
Move the setting of this variable into DetermineGCCCompatible and include that
from both AddLLVM and HandleLLVMStdlib.
Differential Revision: http://reviews.llvm.org/D13216
llvm-svn: 248798
In order to support building clang out-of-tree the install_symlink script needs to be installed, and it needs to be found by searching the CMAKE_MODULE_PATH.
This change renames install_symlink -> LLVMInstallSymlink so it doesn't conflict with naming from other projects, and adds searching behavior in AddLLVM.cmake
llvm-svn: 248009
Summary: This change generalizes symlink generation and makes symlinks to tools obey LLVM_TOOLCHAIN_TOOLS. It makes it so that if you exclude llvm-ar from LLVM_TOOLCHAIN_TOOLS you don't end up with broken symlinks to llvm-lib and llvm-ranlib in your install.
Reviewers: bogner, chapuni, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12864
llvm-svn: 247632
Fix-up for r247305 to use the right variable. There's another use of
LLVM_SOURCE_DIR in this file that is probably also questionable, but it's
for Windows so I'm going to leave it alone.
llvm-svn: 247311
This amends chapuni's r246156 to handle an Xcode quirk, one even called out
in the CMake documentation:
Some native build systems may not like targets that have only object files,
so consider adding at least one real source file to any target that
references $<TARGET_OBJECTS:objlib>.
I've limited the scope of this hack to Xcode for now.
llvm-svn: 247305
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.
We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.
add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.
llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.
One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.
Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
- link all tools and shared libraries to libLLVM if
LLVM_LINK_LLVM_DYLIB is set
- some way of explicitly *not* doing so for utilities
and libLLVM itself
Suggestions for improvement here are particularly welcome.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12590
llvm-svn: 246918
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM.
1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
executables and shared libraries against libLLVM. For this to work, it
is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.
It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
we also default to OFF in this mode, or tools tend to misbehave (e.g.
stdout may not flush on exit when output is buffered.)
llvm-config and Tablegen do not use libLLVM, as they are dependencies of
libLLVM.
2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
Depending on which one is passed (default is component-libs), we link
with the individual libraries or libLLVM respectively. We pass in dylib
when LLVM_LINK_LLVM_DYLIB is ON.
3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
actually export all. Don't strip leading underscore from symbols on Linux,
and make sure we get all exported symbols and weak-with-default symbols
("W" in nm output). Without these changes, passes won't load because
the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
found.
Testing:
- Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
- Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
never had much success with LLDB tests, and llgoi is currently broken
so check-llgo fails for an unrelated reason.
- Ran "lldb" to ensure it loads.
Reviewers: chandlerc, beanz, pcc, rnk
Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits
Differential Revision: http://reviews.llvm.org/D12488
llvm-svn: 246527
If corresponding in-tree subdirectory exists, just ignore LLVM_EXTERNAL* stuff.
Otherwise, set LLVM_TOOL_*_BUILD ON/OFF properly according to LLVM_EXTERNAL_*.
This makes easier to walk among old revisions *without* deleteing CMakeCache.txt.
Before r242059, LLVM_EXTERNAL_* was working like;
if(EXISTS ${*_SOURCE_DIR}/CMakeLists.txt)
set(*_BUILD ON CACHE)
if(*_BUILD is ON)
add_subdirectory(*_SOURCE_DIR)
endif()
endif()
llvm-svn: 245782
This reverts commit r244633.
We aren't going to be able to use it because the compiler-rt build can
be built standalone without an LLVM source dir *or* an installed copy of
LLVM.
llvm-svn: 244648
One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included.
llvm-svn: 242793
Summary:
When calling llgo-go from the llvm_add_go_executable
cmake function, specify $GO_EXECUTABLE as the go
command to call. Without this, llgo-go searches $PATH
which may be inconsistent with $GO_EXECUTABLE.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11290
llvm-svn: 242749
Re-landing r242059 which re-landed r241621... I'm really bad at this.
Summary (r242059):
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.
Summary (r241621):
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:
* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt
Differential Revision: http://reviews.llvm.org/D10665
llvm-svn: 242705
LLVM_EXTERNAL_*_SOURCE_DIR is reset as PATH with set(CACHE PATH).
Then the CACHE PATH variable, LLVM_EXTERNAL_*_SOURCE_DIR, is normalized as
${CMAKE_SOURCE_DIR}/${path_var} if ${path_var} is relative.
llvm-svn: 242120
add_llvm_external_project puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache even if it is just the in-tree default path. This causes all sorts of oddness, and makes it so that I can't change the behavior of this variable.
This patch never puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache. It will only end up in the cache if it is specified on the command line, which is the correct behavior.
There is also a temporary change to remove non-default values from the cache if they are already present. This should have the impact of cleaning out unncecissary values from the caches on the buildbots and people's local build directories. This part of the change is marked with a TODO and can be removed in a few days.
llvm-svn: 242102
Summary:
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.
Original Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:
* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt
Differential Revision: http://reviews.llvm.org/D10665
llvm-svn: 242059
Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:
* factored out canonicalizing tool names from paths to CMake variables
* removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt
Reviewers: bogner, samsonov, chapuni, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10665
llvm-svn: 241621
CMake files and should not be by both build systems and also the targets
were also installed by the CMake build system which they should not be.
The problem was that
- the CMake build of LLVM installs and exports the gtest library
targets. We should not being doing this, these are not part of LLVM.
- the Autoconf/Makefile build of LLVM still had gtest libraries in the
installed LLVMConfig.cmake.
These problems would cause problems for an external project because when
calling llvm_map_components_to_libnames(XXX all) ${XXX} would to contain
LLVM's internal gtest libraries.
llvm-svn: 240981
- Who defines ${LLVM_SOURCE_DIR} ?
- Would windows_version_resource.rc be available in an *installed* llvm tree?
I suggest it may be installed in ${PREFIX}/share.
llvm-svn: 239703
This reinstates my commits r238740/r238741 which I reverted due to a failure
in the clang-cl selfhost tests on Windows. I've now fixed the issue in
clang-cl that caused the failure so hopefully all should be well now.
llvm-svn: 239612
This embeds Windows version information into our executables and DLLs.
The most visible place to view this data is in the details tab of the file
properties window in Windows explorer.
Differential Revision: http://reviews.llvm.org/D7828
llvm-svn: 238740
The CMake install command is defined as:
install(TARGETS targets... [EXPORT <export-name>]
[[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
[DESTINATION <dir>]
[INCLUDES DESTINATION [<dir> ...]]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT <component>]
[OPTIONAL] [NAMELINK_ONLY|NAMELINK_SKIP]
] [...])
This means it can only take one parameter from the set of RUNTIME, LIBRARY, or ARCHIVE. If you set more than one of these it seems to gobble up the extra arguments and ignore the COMPONENT argument.
This adds a check to only set LIBRARY or ARCHIVE based on whether or not the library being built is shared.
llvm-svn: 235113
Added a new boolean CMake flag, LLVM_INSTALL_UTILS. When set,
the 'install' target will include in the bin directory the
utils binaries - e.g. FileCheck. This mirrors the autoconfig
behavior.
Test Plan:
Locally verified that utils binaries are copied when flag is set,
and not copied when flag is not set.
Reviewers: jfb, dschuff, beanz
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8587
Patch by Mircea Trofin
llvm-svn: 233385
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
* Also fixed a minor issue that Duncan pointed out to me I was passing the suite to lit twice
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 233009
Summary:
This change makes CMake scan for lit suites and generate a target for each lit test suite. The targets follow the format check-<project>-<suite path>.
For example:
check-llvm-unit - Runs the LLVM unit tests
check-llvm-codegen-arm - Runs the ARM codeine tests
Note: These targets are not generated during multi-configuration generators (i.e. Xcode and Visual Studio) because target clutter impacts UI usability.
Reviewers: chandlerc
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D8380
llvm-svn: 232671
The MSVC linker won't produce a .lib file for an executable that doesn't
export anything, and LLVM doesn't maintain dllexport annotations or .def
files listing all C++ symbols. It also doesn't support exporting all
symbols, like binutils ld.
CMake 3.2 changed the Ninja generator to list both the .exe and .lib
files as outputs of executable build targets. Ninja would always re-link
executables with ENABLE_EXPORTS because the .lib output file was not
present, and therefore the target was out of date.
llvm-svn: 232662
This allows clang-cl to self-host cleanly with no magic setup
steps required.
After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.
These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.
llvm-svn: 230539
Summary:
* add_llvm_tool and add_llvm_library now add install-${name} targets to install specific components
* added installhdrs target to install just the LLVM headers
* The above changes only apply for single-configuration generators (Ninja, Makefiles...), not for multi-configuration generators (Visual Studio, Xcode...)
Reviewers: pete
Reviewed By: pete
Subscribers: pete, llvm-commits
Differential Revision: http://reviews.llvm.org/D7619
llvm-svn: 229727
This was added in r188351 to fix a naming conflict between the
profile_rt-static and profile_rt-shared who both ended up in
lib/profile_rt.lib.
The change also affected other libraries (like libclang), and
users are reporting that they find it surprising that there's
no longer a libclang.lib. Since the profile_rt naming conflict
doesn't seem to exist any more, I think we can remove this.
Differential Revision: http://reviews.llvm.org/D7391
llvm-svn: 228049
Add the missing `DEPENDS` keyword. r225319 did almost the right thing
(I didn't notice the problem with it because `Kaleidoscope-Ch8` wasn't
building at all).
llvm-svn: 225321
Summary:
This in turn allows us to use #includes with cgo that rely on CMake
provided include directories which is particularly useful for handling
generated headers that aren't reasonable to put in an "installable"
location.
Differential Revision: http://reviews.llvm.org/D6798
llvm-svn: 224962
A shared library (unlike a .a), has its dependencies recorded in the library and
we can pass PRIVATE to target_link_libraries.
This patch then removes some bogus dependencies when using
BUILD_SHARED_LIBS=ON. For example, we go from
build lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/AggressiveAntiDepBreaker.cpp.o:
CXX_COMPILER /home/espindola/llvm/llvm/lib/CodeGen/AggressiveAntiDepBreaker.cpp
|| include/llvm/IR/intrinsics_gen lib/libLLVMSupport.so
lib/libLLVMCore.so lib/libLLVMBitReader.so
lib/libLLVMTransformUtils.so lib/libLLVMInstCombine.so
lib/libLLVMScalarOpts.so lib/libLLVMipa.so lib/libLLVMAnalysis.so
lib/libLLVMMCParser.so lib/libLLVMMC.so lib/libLLVMObject.so
lib/libLLVMTarget.so lib/libLLVMProfileData.so
to
build lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/AggressiveAntiDepBreaker.cpp.o:
CXX_COMPILER /home/espindola/llvm/llvm/lib/CodeGen/AggressiveAntiDepBreaker.cpp
|| include/llvm/IR/intrinsics_gen lib/libLLVMSupport.so
lib/libLLVMCore.so lib/libLLVMTransformUtils.so
lib/libLLVMScalarOpts.so lib/libLLVMAnalysis.so lib/libLLVMMC.so
lib/libLLVMTarget.so
In fact, build.ninja goes from 5231028 bytes to 4896759 bytes.
With this, old verisons of bfd ld (2.24 is OK, 2.23 warns) will print a bogus
warning when building with BUILD_SHARED_LIBS.
llvm-svn: 221530
Summary: This is a fix for the command line syntax error while building LTO when using MinGW.
Patch By: jsroemer
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, beanz, llvm-commits
Differential Revision: http://reviews.llvm.org/D5476
llvm-svn: 220935
the CGO build environment. This lets things like -rpath propagate down
to the C++ code that is built along side the Go bindings when testing
them.
Patch by Peter Collingbourne, and verified that it works by me.
llvm-svn: 220252
It dropped required functions for plugins with gnu ld 2.20 and 2.21.
Failing Tests (1):
LLVM :: Feature/load_module.ll
Hello: bin/opt: symbol lookup error: lib/LLVMHello.so: undefined symbol: _ZN4llvm11raw_ostream13write_escapedENS_9StringRefEb
Failing Tests (1):
Clang :: Frontend/plugins.c
error: unable to load plugin 'lib/PrintFunctionNames.so': 'lib/PrintFunctionNames.so: undefined symbol: _ZN5clang15PluginASTAction6anchorEv'
I think we should inspect linker's version or behavior to introduce --gc-sections for --export-dynamic.
llvm-svn: 220198
This code is based on the existing LLVM Go bindings project hosted at:
https://github.com/go-llvm/llvm
Note that all contributors to the gollvm project have agreed to relicense
their changes under the LLVM license and submit them to the LLVM project.
Differential Revision: http://reviews.llvm.org/D5684
llvm-svn: 219976
to globally be controlled. Individual targets (e.g. ExceptionDemo) can
still override this by using LLVM_REQUIRE_RTTI and LLVM_REQUIRE_EH if
they need to be compiled with RTTI or exception handling respectively.
llvm-svn: 213663
For example, c-index-test.exe requires just libclang.dll (its import library).
When libraries in libclang were not PRIVATE but PUBLIC, c-index-test required libraries transitive by libclang.
Note, on mingw with BUILD_SHARED_LIBS, library dependencies would become more strict.
In principle, required libraries should be "required in its source file".
This will help to detect missing dependencies.
llvm-svn: 212934
FIXME: Make this configurable.
FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for plugins. We may rename it.
I introduced config.enable_shared in r120273.
llvm-svn: 212315
target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.
target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,
- libclang.so has sufficient libclang*.a(s).
- c-index-test requires just only libclang.so.
FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.
llvm-svn: 202241
llvm_add_library(foo SHARED STATIC
DEPENDS <dependent targets...>
LINK_LIBS <required libraries...>
)
It generates both foo (foo.so) and foo_static(foo.a) and both of them depend on DEPENDS and LINK_LIBS.
Then, also obj.foo is generated. obj.foo depends on DEPENDS, but doesn't depend on LINK_LIBS.
llvm-svn: 201854
On unsupported platforms, llvm_add_library(MODULE) doesn't create any targets.
Caller may be responsible to check and add extra target properties.
llvm-svn: 201320
I was insightless then about unknown optional parameters.
(Consider that LINK_LIBS foo bar ADDITIONAL_HEADERS qux quux)
Suggested by Michael Kruse. Thanks!
llvm-svn: 201283
- MODULE;SHARED;STATIC
STATIC by default w/o BUILD_SHARED_LIBS.
SHARED by default w/ BUILD_SHARED_LIBS.
- OUTPUT_NAME name
Corresponds to OUTPUT_NAME in target properties.
- DEPENDS targets...
Same semantics as add_dependencies().
- LINK_COMPONENTS components...
Same as the variable LLVM_LINK_COMPONENTS.
- LINK_LIBS lib_targets...
Same semantics as target_link_libraries().
- ADDITIONAL_HEADERS (implemented in LLVMProcessSources)
May specify header files for IDE generators.
I suggest llvm_add_library() may be used for inter-project add_library stuff
and also suggest add_***_library() may be used project-specific.
Please be patient that llvm_add_library might be ambiguous against add_llvm_library.
llvm-svn: 201072
Record every logical target that we install with install(TARGETS) in a
global LLVM_EXPORTS property. Then use the export(TARGETS) command to
provide a "LLVMExports.cmake" file that exports logical targets for
import into applications directly from our build tree.
The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.
Contributed by Brad King.
llvm-svn: 201050
Use the install(TARGETS) command EXPORT option for every library and
executable that we install with LLVM. Then use the install(EXPORT)
command to provide a "LLVMExports.cmake" file that exports logical
targets for import into applications from our install tree.
The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.
Contributed by Brad King.
llvm-svn: 201049
In trunk, every users assume add_llvm_loadable_module as "loadable module" and no one sets neither SHARED, ... nor also MODULE!
Unfortunately, all loadable modules were linked as not "MODULE" but "SHARED".
If this change caused any regressions, I wish guys to fix it properly. ;)
llvm-svn: 200762
LLVM_REQUIRES_EH implies LLVM_REQUIRES_RTTI. It is as same behavior as Makefile.rule's.
llvm/examples/ExceptionDemo is affected. (It was built with -fno-rtti.)
For MSVC, Remove flags like "/EHsc /GR" in HandleLLVMOptions, or CL.EXE complains with flags like "/GR /GR-".
llvm_update_compile_flags() updates source file property if the target contains *.c.
COMPILE_FLAGS in target properties affects both C++ and C!
LLVM_NO_RTTI is deprecated. It was introduced by me and was my mistake.
llvm-svn: 200301
With this tweaks, also unittests are compiled with -ffunction-sections.
It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible.
llvm-svn: 200299
In LLVM build tree, they points corresponding INTDIR.
In Clang standalone tree, they points external dir (llvm-config's --bindir and --libdir).
llvm-svn: 199595
The generation of the native_export_file end up in
several different makefiles. All those makefiles
write the same file, but can be executed concurrently...
and bad things happen!
llvm-svn: 199356
This is needed to support the addition of tests for clang loadable plugins.
In clang, plugins are built as modules (bundles on OS X) rather than dynamic
libraries (dylib) so the build system needs to inform lit of the actual
file extension in use, typically '.so' on Unix and '.dll' on Windows.
(LLVM itself should probably switch to this scheme to fix PR14903 once and for
all.)
No change in build output or functionality intended.
llvm-svn: 198746
Plugins need to go in build/Debug/lib as well (rather than build/lib/Debug).
Also, fix the SHLIBDIR path for Xcode, which by default includes Xcode build
settings rather than a simple %(build_mode)s parameter.
llvm-svn: 198344
We have been seeing nasty directory layout with CMake multiconfig, such as,
bin/Release/clang.exe
lib/clang/3.x/...
lib/Release/clang/3.x/.. (duplicated)
Move the layout similar to autoconf's;
Release/bin/clang.exe
Release/lib/clang/3.x/...
Checked on Visual Studio 10. Could you guys please confirm my change on XCode(and other multiconfig builders)?
Note: Don't set variables CMAKE_*_OUTPUT_DIRECTORY any more, or a certain builder, for eaxample, msbuild.exe, would be confused.
llvm-svn: 198205
The windows ninja build is now green, but msvs is still unhappy. Maybe that's
because the .def file was passed when building LTO_static, so only pass
symbol lists for shared libraries.
llvm-svn: 198151
The command that cmd.exe is complaining about is:
cmd.exe /c cd /D C:\bb-win7\cmake-clang-i686-mingw32\build\tools\lto && cmake -E echo EXPORTS > symbol.def && type C:/bb-win7/cmake-clang-i686-mingw32/llvm-project/llvm/tools/lto/lto.exports >> symbol.def
Maybe quoting the filename helps.
llvm-svn: 198140
The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a
Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only
implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation
in tools/clang/tools/libclang/CMakeLists.txt.
This attempts to consolidate these one-offs into a single place. Clients can now
just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in
the make build.
llvm-svn: 198136
Allow CMake to pick up external projects in llvm/tools without the need to modify the "llvm/tools/CMakeLists.txt" file.
This makes it easier to work with projects that live in other repositories, without needing to specify each one in "llvm/tools/CMakeLists.txt".
llvm-svn: 188921
CMake and autotools disagree on what "host" means in a cross-compilation
context. Autotools (and lit) take it to be the machine the binaries being
compiled now will run on. CMake takes it to be the machine actually compiling
the binaries now.
This change makes lit.site-cfg more consistent between autotools and CMake,
allowing lit tests (particularly in ExecutionEngine) to run correctly when
cross-compiled with CMake
llvm-svn: 175179
For example,
cur) unittests/ADT/Release/ADTTests
new) unittests/ADT/ADTTests
RUNTIME_BUILD_MODE can be substituted to CMAKE_CFG_INTDIR.
With Make and Ninja, the tree is not built with multiple configurations.
Then, including the build type in target directory doesn't make sense.
See also "How can I build multiple modes without switching?"
http://www.cmake.org/Wiki/CMake_FAQ
CMAKE_CFG_INTDIR is set to "."
With multiple-configuration-aware build system, like Visual Studio, each unittest is built on appropriate directory, for example,
unittests/ADT/Release/ADTTests.exe
CMAKE_CFG_INTDIR is set to build system's variable, like "$(Configuration)" or "$(OutDir)".
Thus, "--param build_config" is also deprecated.
llvm-svn: 173616
"check-all" can be executed with 0 status, "check-all does nothing, no tools built."
LLVM_EXTERNAL_CLANG_BUILD=OFF LLVM_BUILD_TOOLS=OFF can reproduce this.
Oscar Fuentes reported this. Thank you.
llvm-svn: 171046
- Substitute hyphen to underscore, s/-/_/g, as the variable name.
- Additional parameter can be specified as the name of directory.
e.g.) add_llvm_external_project(clang-tools-extra extra)
- LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR=/path/to/llvm-srcroot/tools/clang/tools/extra, by default.
- Build directory is in ${CMAKE_CURRENT_BINARY_DIR}/extra
llvm-svn: 165311
in the abstraction for lit test suites so that the various other layers
of abstraction pick up the same behavioral fix, and so that we still get
a complete list of dependencies for the 'check-all' target.
This should fix the follow-on issues of the same nature with various
other build targets, including Clang targets. Sorry for the churn, and
again thanks to Matt for testing and breaking this more thoroughly.
llvm-svn: 159593
re-used. Also, build in direct support for accumulating a set of lit
parameters, arguments, and testsuites to run as part of a 'check-all'
rule. This sinks 'check-all' from a Clang-specific construct to
a generic construct of the project.
llvm-svn: 159482
Chris Bieneman