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
gtest and gtest_main) when generating ``Makefile.llvmbuild``.
Libraries that are not installed should not be exported because they
won't be available from an install tree. Rather than filtering out the
gtest libraries in cmake/modules/Makefile, simply teach llvm-build to
filter out libraries that will not be installed from its generated list
of exported libraries.
Note that LLVMBUILD_LIB_DEPS_* are used during our own CMake build
process so we cannot filter LLVMBUILD_LIB_DEPS_gtest* out in llvm-build.
We must leave this gtest filter logic in cmake/modules/Makefile.
llvm-svn: 245718
Brad King.
Move `LLVM_LIBS_TO_EXPORT` over to Makefile.llvmbuild and generate it
from `llvm-build` using the same logic used to export the dependencies
of these libraries. This avoids depending on `llvm-config`.
This refactoring was originally motivated by issue #24154 due to commit
r243297 (Fix `llvm-config` to emit the linker flag for the combined
shared object, 2015-07-27) changing the output of `llvm-config --libs`
to not have the individual libraries when we configure with
`--enable-shared`. That change was reverted by r244108 but this
refactoring makes sense on its own anyway.
llvm-svn: 245717
such as std::equal on the third argument. This reverts previous workarounds.
Predefining _DEBUG_POINTER_IMPL disables Visual C++ 2013 headers from defining
it to a function performing the null pointer check. In practice, it's not that
bad since any function actually using the nullptr will seg fault. The other
iterator sanity checks remain enabled in the headers.
Reviewed by Aaron Ballmanþ and Duncan P. N. Exon Smith.
llvm-svn: 245711
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
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.
Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.
llvm-svn: 243957
This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.
Differential Revision: http://reviews.llvm.org/D10707
llvm-svn: 243419
Prior to CMAKE 2.8.4 that was covered by the WIN32 conditional but
from 2.8.4 CMAKE no longer defined WIN32 when running under Cygwin
and it needs its own test.
Patch by Martell Malone!
http://reviews.llvm.org/D11347
llvm-svn: 242993
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
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
llvm-svn: 241271
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.
llvm-svn: 241080
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
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.
llvm-svn: 240882
Summary:
Finally, delete LLVM's parse_arguments() definition.
Second part of D10531.
This is dependent on http://reviews.llvm.org/D10529
Reviewers: pcc, beanz, chapuni
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10531
llvm-svn: 240122
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
llvm-svn: 239819
- 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
OCaml doc builds fail without .cmi files, and .cmi files are collected
in ocaml_outputs. Therefore, make doc targets depend on ocaml_outputs as
well.
Fixes: https://llvm.org/bugs/show_bug.cgi?id=23777
Patch by Michał Górny <mgorny@gentoo.org>
llvm-svn: 239259
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
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
llvm-svn: 238592
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.
llvm-svn: 237743
