summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules/TableGen.cmake
Commit message (Collapse)AuthorAgeFilesLines
* [CMake] Fixing dependency issue with parallel make when building with ↵Chris Bieneman2015-10-231-1/+8
| | | | | | | | LLVM_OPTIMIZED_TABLEGEN. Patch by Alex Wang llvm-svn: 251138
* [CMake] Parallel make breaks on native tablegenChris Bieneman2015-10-091-1/+10
| | | | | | | | Patch by Alex Wang This patch resolves a parallelization issue that occurs when native tablegen targets are built at the same time. They both try to build libSupport and clobber each other causing the builds to fail. llvm-svn: 249911
* [cmake] rework LLVM_LINK_LLVM_DYLIB option handlingAndrew Wilkins2015-09-051-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Don't use OBJLIB on Xcode.NAKAMURA Takumi2015-09-021-2/+4
| | | | | | I got a few reports it didn't work. llvm-svn: 246629
* Enable linking tools, shared libraries against libLLVMAndrew Wilkins2015-09-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] OBJLIB-ize *-tblgen.NAKAMURA Takumi2015-08-271-0/+4
| | | | | | | | | | | | This improves dependency chain of; (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen) with; (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen) llvm-svn: 246156
* [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
* [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
* Fixing dependencies for native tablegen.Chris Bieneman2015-03-191-4/+2
| | | | | | | | | | | The dependencies for cross-built tablegen were a bit confused. This fixes that. The following dependencies are now enforced: (1) Tablegen tasks depend on the native tablegen (2) Native tablegen depends on the cross-compiled tablegen Although the native tablegen doesn't actually require the cross tablegen, having this dependency forces the native tablegen to rebuild whenever the cross tablegen changes. llvm-svn: 232730
* Refactoring CMake CrossCompile module.Chris Bieneman2015-03-121-1/+1
| | | | | | | | | * put most of the cross-compiling support into a function llvm_create_cross_target_internal. * when CrossCompile is included it still generates a NATIVE target. * llvm_create_cross_target function takes a target_name which should match a toolchain. * llvm_create_cross_target can now be used to target more than one cross-compilation target. llvm-svn: 232067
* Add new LLVM_OPTIMIZED_TABLEGEN build setting which configures, builds and ↵Chris Bieneman2015-03-101-1/+1
| | | | | | | | | | | | | | | | uses a release tablegen build when LLVM is configured with assertions enabled. Summary: This change leverages the cross-compiling functionality in the build system to build a release tablegen executable for use during the build. Reviewers: resistor, rnk Reviewed By: rnk Subscribers: rnk, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D7349 llvm-svn: 231842
* Enabling LLVM & Clang to be cross-compiled using CMake from a single ↵Chris Bieneman2014-09-031-34/+5
| | | | | | | | configuration command line The basic idea is similar to the existing cross compilation support. A directory must be configured to build host versions of tablegen tools and llvm-config. This directory can be user provided (and configured), or it can be created during the build. During a build the native build directory will be configured and built to supply the tablegen tools used during the build. A user could also explicitly provide the tablegen executables to run on the CMake command line. llvm-svn: 217105
* CMake: avoid a reconfigure loop from r213091Alp Toker2014-07-151-2/+1
| | | | | | | Removing the native CMakeCache.txt causes the target to get re-run needlessly on some systems. We'll want another solution for that part of the fix. llvm-svn: 213099
* CMake: fix cross-compilation with external source directoriesAlp Toker2014-07-151-1/+11
| | | | | | | | This adds support for building native artifacts when cross-compiling using the popular side-by-side source directory layout (no symlinks, no nested repositories). llvm-svn: 213091
* TableGen.cmake: Functionalize and reformat.NAKAMURA Takumi2014-02-231-16/+17
| | | | llvm-svn: 201972
* [CMake] Move intrinsics_gen to lib/Target out of add_public_tablegen_target.NAKAMURA Takumi2014-02-201-1/+1
| | | | | | add_public_tablegen_target is used somewhere. llvm-svn: 201787
* Teach tablegen() macro to check needed variablesNAKAMURA Takumi2014-02-121-0/+11
| | | | | | | | | | | This macro depends on several variables to be set in the calling context. Check them and report an error if they are not set. Without this, custom commands may be silently specified that will fail at build time. Patch by Brad King. llvm-svn: 201229
* [CMake] LLVMSupport should be responsible to provide system_libs.NAKAMURA Takumi2014-02-101-5/+0
| | | | llvm-svn: 201077
* Whitespace.NAKAMURA Takumi2014-02-091-4/+4
| | | | llvm-svn: 201054
* Export lib and exe build target names from build treeNAKAMURA Takumi2014-02-091-0/+1
| | | | | | | | | | | | | | | 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
* Export lib and exe build target names from install treeNAKAMURA Takumi2014-02-091-1/+3
| | | | | | | | | | | | | | | 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
* Revert r200150, "[CMake] tablegen(): Use -I <dir> according to the list by ↵NAKAMURA Takumi2014-02-041-17/+5
| | | | | | | | | include_directories()." It missed include/llvm/Target. Could I avoid GLOB_RECURSE anyways? :( FYI, I intended to prune ${LLVM_MAIN_INCLUDE_DIR} in TableGen.cmake in r200150. llvm-svn: 200730
* [CMake] tablegen(): Use -I <dir> according to the list by include_directories().NAKAMURA Takumi2014-01-261-5/+17
| | | | | | For now, local_tds and global_tds are integrated to dependent_tds. llvm-svn: 200150
* [CMake] Functionalize tblgen().NAKAMURA Takumi2014-01-261-3/+3
| | | | llvm-svn: 200149
* [CMake] Add a comment to tablegen's copy_if_different. Ninja reports every ↵NAKAMURA Takumi2014-01-121-1/+1
| | | | | | action by default. llvm-svn: 199058
* Remove CMake-Xcode hack that symlinked llvm-config into a common place.Douglas Gregor2014-01-021-10/+0
| | | | | | | When building Clang separately from LLVM with CMake, one should set the path of llvm-config via the cache variable LLVM_CONFIG. llvm-svn: 198316
* [CMake] Don't put every project's tblgen executable in the LLVM bin directory.Jordan Rose2013-12-181-2/+0
| | | | | | | | | This changes Clang standalone builds so that clang-tblgen lives in clang/build/bin instead of llvm/build/bin, and so that with the Xcode generator it's in clang/build/bin/Debug instead of llvm/build/bin/Debug/Debug/. Yes, really. llvm-svn: 197590
* [CMake] ${LLVM_MAIN_SRC_DIR}/include can be represented as ↵NAKAMURA Takumi2013-12-161-1/+1
| | | | | | ${LLVM_MAIN_INCLUDE_DIR}. llvm-svn: 197396
* [CMake] Let add_public_tablegen_target() provide intrinsics_gen, too.NAKAMURA Takumi2013-11-281-1/+1
| | | | | | | | | | I think, in principle, intrinsics_gen may be added explicitly. That said, it can be added incidentally, since each target already has dependencies to llvm-tblgen. Almost all source files depend on both CommonTaleGen and intrinsics_gen. Explicit add_dependencies() have been pruned under lib/Target. llvm-svn: 195929
* [CMake] Let add_public_tablegen_target responsible to provide dependency to ↵NAKAMURA Takumi2013-11-281-2/+3
| | | | | | | | | CommonTableGen. add_public_tablegen_target adds *CommonTableGen to LLVM_COMMON_DEPENDS. LLVM_COMMON_DEPENDS affects add_llvm_library (and other add_target stuff) within its scope. llvm-svn: 195927
* Revert "Revert "Windows: Add support for unicode command lines""David Majnemer2013-10-071-1/+1
| | | | | | | This reverts commit r192070 which reverted r192069, I forgot to regenerate the configure scripts. llvm-svn: 192079
* Revert "Windows: Add support for unicode command lines"David Majnemer2013-10-061-1/+1
| | | | | | | This is causing MinGW bots to fail. This reverts commit r192069. llvm-svn: 192070
* Windows: Add support for unicode command linesDavid Majnemer2013-10-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVCRT deliberately sends main() code-page specific characters. This isn't too useful to LLVM as we end up converting the arguments to UTF-16 and subsequently attempt to use the result as, for example, a file name. Instead, we need to have the ability to access the Unicode command line and transform it to UTF-8. This has the distinct advantage over using the MSVC-specific wmain() function as our entry point because: - It doesn't work on cygwin. - It only work on MinGW with caveats and only then on certain versions. - We get to keep our entry point as main(). :) N.B. This patch includes fixes to other parts of lib/Support/Windows s.t. we would be able to take advantage of getting the Unicode paths. E.G. clang spawning clang -cc1 would want to give it Unicode arguments. Reviewers: aaron.ballman, Bigcheese, rnk, ruiu Reviewed By: rnk CC: llvm-commits, ygao Differential Revision: http://llvm-reviews.chandlerc.com/D1834 llvm-svn: 192069
* cmake: Install llvm-tblgen againHans Wennborg2013-09-101-0/+4
| | | | | | | | | | | It was removed in r189130, but it turns out this makes life hard for folks packaging LLVM and Clang and building the latter based on the LLVM package. Note that this only adds back the LLVM tblgen, and it's obviously not included when LLVM_INSTALL_TOOLCHAIN_ONLY is set. llvm-svn: 190419
* CMake Xcode builds: symlink tblgen targets out to bin/.Douglas Gregor2013-08-261-0/+10
| | | | | | | | | | | Xcode always puts executable targets in the directory bin/<Config>. When building separate LLVM and Clang projects for Xcode, this prevents the CMake-configured project for Clang from finding llvm-tblgen. Add a symlink so that tblgen executables are always available in bin/ (regardless of the configuration LLVM is built with). llvm-svn: 189220
* CMake: don't install tablegenHans Wennborg2013-08-231-2/+0
| | | | | | | | Since it's an llvm-internal tool, we shouldn't install it. (This depends on Clang r189127 and lld r189128.) llvm-svn: 189130
* Pass -G argument to cmake with the same generator's name as used for theSimon Atanasyan2013-08-011-1/+2
| | | | | | | | initial cmake invocation. Patch reviewed by Reid Kleckner. llvm-svn: 187591
* TableGen.cmake: Fix to work without LLVM_COMMON_DEPENDS.NAKAMURA Takumi2012-06-171-1/+3
| | | | llvm-svn: 158650
* CMake: Add the folder "Tablegenning" on llvm-tblgen targets.NAKAMURA Takumi2012-01-301-0/+1
| | | | llvm-svn: 149219
* Fix a typo noticed by Peter Collingbourne. No one depends on thisChandler Carruth2011-11-021-1/+1
| | | | | | | working today, but it shouldn't corrupt state for some poor soul to debug later. llvm-svn: 143545
* The TableGen parts of the CMake build are seriously broken. This fixesChandler Carruth2011-11-021-1/+3
| | | | | | | | | | | | | | one aspect of them by having them use the (annoying, if not broken) proper library dependency model for adding the LLVMTableGen library as a dependency. This could manifest as a link order issue in the presence of separate LLVM / Clang source builds with CMake and a linker that really cares about such things. Also, add the Support dependency to llvm-tblgen itself so that it doesn't rely on TableGen's transitive Support dependency. A parallel change for clang-tblgen will be forthcoming. llvm-svn: 143531
* Build system infrastructure for multiple tblgens.Peter Collingbourne2011-10-061-3/+73
| | | | llvm-svn: 141266
* Clean up a pile of hacks in our CMake build relating to TableGen.Chandler Carruth2011-07-261-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first problem to fix is to stop creating synthetic *Table_gen targets next to all of the LLVM libraries. These had no real effect as CMake specifies that add_custom_command(OUTPUT ...) directives (what the 'tablegen(...)' stuff expands to) are implicitly added as dependencies to all the rules in that CMakeLists.txt. These synthetic rules started to cause problems as we started more and more heavily using tablegen files from *subdirectories* of the one where they were generated. Within those directories, the set of tablegen outputs was still available and so these synthetic rules added them as dependencies of those subdirectories. However, they were no longer properly associated with the custom command to generate them. Most of the time this "just worked" because something would get to the parent directory first, and run tablegen there. Once run, the files existed and the build proceeded happily. However, as more and more subdirectories have started using this, the probability of this failing to happen has increased. Recently with the MC refactorings, it became quite common for me when touching a large enough number of targets. To add insult to injury, several of the backends *tried* to fix this by adding explicit dependencies back to the parent directory's tablegen rules, but those dependencies didn't work as expected -- they weren't forming a linear chain, they were adding another thread in the race. This patch removes these synthetic rules completely, and adds a much simpler function to declare explicitly that a collection of tablegen'ed files are referenced by other libraries. From that, we can add explicit dependencies from the smaller libraries (such as every architectures Desc library) on this and correctly form a linear sequence. All of the backends are updated to use it, sometimes replacing the existing attempt at adding a dependency, sometimes adding a previously missing dependency edge. Please let me know if this causes any problems, but it fixes a rather persistent and problematic source of build flakiness on our end. llvm-svn: 136023
* CMake: generalize the system that creates custom targets forOscar Fuentes2011-07-251-0/+21
| | | | | | tablegenning to all libraries and executables. llvm-svn: 135908
* Add the tablegenned files to the `clean' target.Oscar Fuentes2011-02-041-0/+5
| | | | llvm-svn: 124854
* Changes for building Clang and others using LLVM as an externalOscar Fuentes2011-02-031-1/+2
| | | | | | | | | | | | | library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
* TableGen.cmake: sometimes the .td file is not in the current directoryOscar Fuentes2011-01-031-1/+4
| | | | | | | | | | | (clang/include/clang/Basic/StmtNodes.td, for instance, is tablegenned from clang/include/clang/AST/CMakeLists.txt) so it is not contained on the list of all .td files on the current source directory which is used as the DEPENDS of the custom command. We must add the .td file to the DEPENDS list of the custom command. Otherwise some .inc files are not regenerated when the corresponding .td file changes. llvm-svn: 122768
* Avoid stalled file dependency when tablegenning.Oscar Fuentes2010-10-221-5/+7
| | | | | | Patch by Frits van Bommel! llvm-svn: 117113
* Teach CMake to only touch tablegen-generated files if anythingOscar Fuentes2010-10-221-1/+10
| | | | | | | | actually changed. Patch by Frits van Bommel! llvm-svn: 117102
* Allow absolute paths in LLVM_TARGET_DEFINITIONS for CMake's TableGen ruleDouglas Gregor2010-06-171-1/+7
| | | | llvm-svn: 106219
OpenPOWER on IntegriCloud