summaryrefslogtreecommitdiffstats
path: root/llvm/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* [cmake] Add helper for finding potentially external projectsReid Kleckner2015-08-111-0/+17
| | | | | | | I plan to use this from compiler-rt, but it's useful for any LLVM project that depends on more than just LLVM. llvm-svn: 244633
* Remove the configure and cmake checks for sys/wait.hJustin Bogner2015-08-041-1/+0
| | | | | | | | | | 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
* Use a specified list of languages in cmake project() command.Douglas Katzman2015-07-281-0/+1
| | | | | | | | | | | 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
* build: fix small typo in cmake doxygen buildSaleem Abdulrasool2015-07-241-1/+1
| | | | | | | | | A search word spelled as "searhc" in the LLVM_DOXYGEN_SEARCHENGINE_URL cmake variable docstring. Patch by Daniel Otero! llvm-svn: 243082
* Avoid using -Wl,-z,defs on Cygwin.Yaron Keren2015-07-231-1/+1
| | | | | | | | | | | | 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
* [CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be ↵Chris Bieneman2015-07-211-10/+0
| | | | | | | | explicitly specified. 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
* [cmake] pass GO_EXECUTABLE to llgo-goAndrew Wilkins2015-07-211-1/+1
| | | | | | | | | | | | | | | | 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
* [CMake] Fixing inconsistency caused by copy-pasta.Chris Bieneman2015-07-211-2/+2
| | | | | | This will actually fix the PR 24194. llvm-svn: 242748
* [CMake] Fixing a problem with external projects that aren't getting enabled ↵Chris Bieneman2015-07-211-0/+4
| | | | | | | | properly. This should address PR 24194, and some builedbot failures. llvm-svn: 242746
* Suppress two warnings from MSVC 2015 that are triggered under /W4. Since we ↵Aaron Ballman2015-07-201-0/+2
| | | | | | turn off exceptions in the code base, C4577 is moot. C4091 triggers on system headers and is a benign construct. llvm-svn: 242708
* [CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-201-28/+63
| | | | | | | | | | | | | | | | | | | | | auto-registration that was already partially working. 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
* [CMake] Unbreak add_llvm_external_project when external projects are specified.NAKAMURA Takumi2015-07-141-0/+3
| | | | | | | | 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
* [CMake] Forgot to quote the first part of STREQUAL.Chris Bieneman2015-07-141-1/+1
| | | | llvm-svn: 242103
* [CMake] We shouldn't be storing values in the cache unless they actually ↵Chris Bieneman2015-07-141-4/+9
| | | | | | | | | | | | need CMake cache behavior. 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
* Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-131-64/+21
| | | | | | | | auto-registration that was already partially working." Reverting r242059 because it broke some bots. I'm attempting to reproduce the failures now. llvm-svn: 242060
* [CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-131-21/+64
| | | | | | | | | | | | | | | | | | | auto-registration that was already partially working. 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
* Revert r241621, "[CMake] Cleanup tools/CMakeLists.txt to take advantage of ↵NAKAMURA Takumi2015-07-081-31/+19
| | | | | | | | the auto-registration that was already partially working." It broke the build that relies on LLVM_EXTERNAL_CLANG_*. llvm-svn: 241663
* [CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-071-19/+31
| | | | | | | | | | | | | | | | | | | | | auto-registration that was already partially working. 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] add_llvm_symbol_exports: Use Python oneliner instead of "cmd.exe /c ↵NAKAMURA Takumi2015-07-051-13/+2
| | | | | | type" to generate *.def. llvm-svn: 241402
* [Support] Lazy load of dbghlp.dll on WindowsLeny Kholodov2015-07-021-2/+0
| | | | | | | | | | | | | 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
* [CMake] Make the CMake files (LLVMConfig.cmake and LLVMExports.cmake)Dan Liew2015-06-301-9/+27
| | | | | | | | | | | | | | | | | | 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
* [WebAssembly] Initial WebAssembly backendDan Gohman2015-06-291-0/+4
| | | | | | | This WebAssembly backend is just a skeleton at this time and is not yet functional. llvm-svn: 241022
* Fix bug #23967. The gtest and gtest_main targets were exported into theDan Liew2015-06-292-3/+16
| | | | | | | | | | | | | | | | | | | 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
* [OCaml] Bump ctypes dependency to 0.4.Peter Zotov2015-06-271-2/+2
| | | | | | | | | | | | 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
* Spelling fixes in comments.Douglas Katzman2015-06-241-2/+2
| | | | llvm-svn: 240594
* Support Solaris unused sections' gc link syntax.Rafael Espindola2015-06-221-0/+3
| | | | | | | | | 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. llvm-svn: 240287
* Do not pass optimization flags to Solaris' linker.Rafael Espindola2015-06-221-1/+1
| | | | | | | | It is not supported. Patch by Xan López. llvm-svn: 240276
* Use right syntax to pass version script to Solaris' ld.Rafael Espindola2015-06-221-2/+7
| | | | | | Patch by Xan Lopez! llvm-svn: 240275
* CMake: Stop using LLVM's custom parse_arguments (delete implementation). NFCFilipe Cabecinhas2015-06-191-80/+0
| | | | | | | | | | | | | | | | 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
* CMake: Stop using LLVM's custom parse_arguments. NFCFilipe Cabecinhas2015-06-191-8/+7
| | | | | | | | | | | | | | | | | | Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Reviewers: pcc, beanz, chapuni Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10531 llvm-svn: 240121
* Silence resource compiler using /nologo flag.Peter Collingbourne2015-06-181-0/+2
| | | | llvm-svn: 239983
* Repair cmake libatomic check.James Y Knight2015-06-161-6/+36
| | | | | | | | | | | | | | 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
* [CMake] Try to fix r239612, not to miss ↵NAKAMURA Takumi2015-06-141-3/+5
| | | | | | | | | | resources/windows_version_resource.rc in clang build. - 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
* In MSVC builds embed a VERSIONINFO resource in our exe and DLL files.Greg Bedwell2015-06-121-0/+82
| | | | | | | | 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
* [cmake] [OCaml] Make ocamldoc targets depend on output filesPeter Zotov2015-06-071-1/+1
| | | | | | | | | | | | 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
* [CMake] Revert commits r238740/r238741 for embedding Windows version info.Greg Bedwell2015-06-011-82/+0
| | | | | | | The clang Windows bots are showing mysterious failures. Reverting until I can figure out what's going on. llvm-svn: 238744
* remove the use of the LOCATION CMake variable from r238740.Greg Bedwell2015-06-011-4/+0
| | | | | | | It caused the following failure: "Policy CMP0026 is not set: Disallow use of the LOCATION target property." llvm-svn: 238741
* In MSVC builds embed a VERSIONINFO resource in our exe and DLL files.Greg Bedwell2015-06-011-0/+86
| | | | | | | | | | 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
* [CMake] Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual StudioChris Bieneman2015-05-291-1/+5
| | | | | | | | | | | | | | 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
* Try to fix the build with MSVC 2015 by disabling sized deallocationReid Kleckner2015-05-191-0/+5
| | | | | | | | | | | 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
* Use cat and not type Under MSYS, same as Cygwin.Yaron Keren2015-05-191-1/+1
| | | | | | | | type means something else under the MSYS shell. Patch by Tzafrir Poupko! llvm-svn: 237692
* cmake: Use -fno-sanitize-recover=all - the old spelling is deprecatedJustin Bogner2015-05-141-2/+2
| | | | llvm-svn: 237334
* Allow the CMake option 'LLVM_ABI_BREAKING_CHECKS' to be undefined.Eric Fiselier2015-05-121-0/+3
| | | | | | | When building libc++abi in a standalone configuration the CMake option 'LLVM_ABI_BREAKING_CHECKS` will not be defined. llvm-svn: 237204
* [lib/Fuzzer] use -fsanitize-coverage=trace-cmp when building LLVM with ↵Kostya Serebryany2015-05-081-1/+1
| | | | | | LLVM_USE_SANITIZE_COVERAGE; in lib/Fuzzer try to reload the corpus to pick up new units from other processes llvm-svn: 236906
* Update CMake flags, LibFuzzer comments and docs for new -fsanitize-coverage= ↵Alexey Samsonov2015-05-071-1/+1
| | | | | | flags. llvm-svn: 236797
* [CMake] Also search for prefixed versions of ld.goldNiels Ole Salscheider2015-05-011-1/+1
| | | | llvm-svn: 236312
* Allow building the gold plugin even if the gold binary is not found.Rafael Espindola2015-04-271-4/+2
| | | | | | | | 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. llvm-svn: 235918
* [CMake] Fix for PR 23328: LLVM_OPTIMIZED_TABLEGEN brokenChris Bieneman2015-04-241-3/+4
| | | | | | | | | | | | 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. llvm-svn: 235732
* [cmake] Quote the path to the target exports file, fixes PR23313Reid Kleckner2015-04-221-1/+1
| | | | llvm-svn: 235519
* Silence MSVC build alignment warningsAndrew Kaylor2015-04-211-1/+9
| | | | llvm-svn: 235450
OpenPOWER on IntegriCloud