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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242120 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242102 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242059 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241621 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes linkage with dbghlp.dll for clang from static (at load time)
to on demand (at the first use of required functions). Clang uses dbghlp.dll
only in minor use-cases. First of all in case of crash and in case of plugin load.
The dbghlp.dll library can be absent on system. In this case clang will fail
to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll
is not available.
Differential Revision: http://reviews.llvm.org/D10737
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241271 91177308-0d34-0410-b5e6-96231b3b80d8
generated by the Autoconf/Makefile build system relocatable.
Previously the generated CMake files contained hardcoded paths which
prevented a binary installation from being relocated to a different
place in the file system. This problem was most noticeable in LLVM's
official binary releases which were completely unusable by a downstream
project trying to import the CMake targets.
Package maintainers who choose to modify the install location of the
CMake directory without using the ``PROJ_cmake`` Makefile variable
override will need to patch the generated``LLVMConfig.cmake`` so that
``LLVM_INSTALL_PREFIX`` and ``_LLVM_CMAKE_DIR`` variables are set
correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241080 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240981 91177308-0d34-0410-b5e6-96231b3b80d8
ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.
Unbreak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240882 91177308-0d34-0410-b5e6-96231b3b80d8
It is not clear if this would work or not with LLVM_NO_DEAD_STRIP
binaries, so be conservative for now.
Patch by Xan López.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240287 91177308-0d34-0410-b5e6-96231b3b80d8
The cmake check for whether libatomic could be used had been
unconditionally setting the result to false. Which was somewhat
fortunate, because the prerequisite check for whether it was *needed*
was always claiming it was, even if it was not.
However, this made platforms where libatomic is actually necessary
fail to link.
Differential Revision: http://reviews.llvm.org/D10453
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239819 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239703 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239612 91177308-0d34-0410-b5e6-96231b3b80d8
The clang Windows bots are showing mysterious failures.
Reverting until I can figure out what's going on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238744 91177308-0d34-0410-b5e6-96231b3b80d8
It caused the following failure:
"Policy CMP0026 is not set: Disallow use of the LOCATION target property."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238741 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238740 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Multi-configuration builds put their binaries into ${CMAKE_BINARY_DIR}/Release/bin/. The table-gen cross-compilation support needs to take that into account.
Reviewers: yaron.keren
Reviewed By: yaron.keren
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10102
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238592 91177308-0d34-0410-b5e6-96231b3b80d8
I can't actually test this properly because uninstalling MSVC 2015 CTP 6
and reinstalling the 2015 RC takes hours. I can only verify that this
doesn't mess up MSVC 2013 and 2015 CTP 6 builds, which is what I've
done.
Should fix PR23513.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237743 91177308-0d34-0410-b5e6-96231b3b80d8
When building libc++abi in a standalone configuration the CMake option
'LLVM_ABI_BREAKING_CHECKS` will not be defined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237204 91177308-0d34-0410-b5e6-96231b3b80d8
The gold binary is not required to build the plugin. All that is
needed is for LLVM_BINUTILS_INCDIR to point to the directory
containing plugin-api.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235918 91177308-0d34-0410-b5e6-96231b3b80d8
In CMake dependencies can be filenames or targets, and targets can't be filenames. The Ninja generator handles filename dependencies because it generates targets for every output file from a command. For example:
add_custom_command(OUTPUT foo.txt COMMAND touch foo.txt)
With the Ninja generator this generates a target foo.txt, but with the Makefile generator it doesn't. This is probably because Ninja explicitly requires these hard dependency ties, and Make just behaves oddly in general.
To fix this we need to make the tablegen actions depend on a target rather than a filename.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235732 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend.
- AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos
A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets.
Reviewed by Chris Bieneman.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235324 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235113 91177308-0d34-0410-b5e6-96231b3b80d8
Certain versions of CMake specify /W3 as part of CMAKE_CXX_FLAGS
by default, before you do anything. Appending /W4 to the end of
this and using the Ninja generator results in
cl : Command line warning D9025 : overriding '/W3' with '/W4'.
It is not possible to suppress this since it is a command line
warning and not a compiler warning, so we must fix the command
line to contain only one value for /Wn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234907 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, on ELF there is not used attribute on the .o files,
so there is no easy way to keep the dump function alive.
If we are not gcing, we may as well produce non gcable files and
avoid the cost.
Linking a debug clang now takes 18.856225992 seconds, before it
took 21.206897447.
I will try avoiding --gc-sections -O3 on a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234159 91177308-0d34-0410-b5e6-96231b3b80d8
