summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules/LLVM-Config.cmake
Commit message (Collapse)AuthorAgeFilesLines
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* Fix use of add_llvm_tool in projects that build no targetsKevin Petit2019-11-141-1/+1
| | | | | | | | | | | | | Projects that set LLVM_TARGETS_TO_BUILD to an empty list can't use add_llvm_tool (and probably other macros). Here's the error that this change fixes: list sub-command REMOVE_ITEM requires two or more arguments. https://reviews.llvm.org/D70167 Signed-off-by: Kevin Petit <kevin.petit@arm.com>
* [cmake] Remove confusing condition argument from else() NFCTom Stellard2019-11-131-1/+1
| | | | | | | | | | | | | | | | Summary: This makes it look like an elseif and also the variable referenced in the condition was removed from this function in r366622. Reviewers: dsanders, beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70159
* Re-commit: r366610 and r366612: Expand pseudo-components before embedding in ↵Daniel Sanders2019-07-191-72/+89
| | | | | | | | | | | | | | | | | llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
* Revert r366610 and r366612: Expand pseudo-components before embedding in ↵Daniel Sanders2019-07-191-86/+70
| | | | | | | | | | llvm-config Some targets are missing LLVMDemangle, one is adding the LLVM prefix twice, and two are hitting the very error this patch fixes for my target. Reverting while I work through the reports. llvm-svn: 366615
* Fix a latent bug discovered by r366610: nativecodegen includes X86CodeGen ↵Daniel Sanders2019-07-191-1/+3
| | | | | | | | | | | | when X86 is not compiled I believe this to have been a latent bug as the same expansion checks for the existence of ${native_tgt}Info and ${native_tgt}Desc and only adds them if they were compiled but unconditionally adds ${native_tgt}CodeGen. This should fix llvm-clang-x86_64-win-fast which builds ARM only on an X86 host and similar builders. llvm-svn: 366612
* Expand pseudo-components before embedding in llvm-configDaniel Sanders2019-07-191-70/+84
| | | | | | | | | | | | | | | | | | | | Summary: If you use pseudo-targets like AllTargetsCodeGens in LLVM_DYLIB_COMPONENTS then a test will fail because `./bin/llvm-config --shared-mode` can't handle these targets. We can fix this by expanding them before embedding the string into llvm-config Reviewers: bogner Reviewed By: bogner Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65011 llvm-svn: 366610
* Fix BUILD_SHARED_LIBS builds after r361567Daniel Sanders2019-05-241-1/+1
| | | | | | Also fixed a comment I noticed while debugging this build llvm-svn: 361591
* Break false dependencies on target librariesDaniel Sanders2019-05-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
* [CMake] Avoid REVERSE on unset variableSven van Haastregt2018-09-261-1/+3
| | | | | | | | | | | | | | If required_libs happens to remain unset, CMake would fail with: list sub-command REVERSE requires list to be present. Fix by ensuring we do not attempt to reverse an unset variable. Reported by Tu Vuong. Differential Revision: https://reviews.llvm.org/D51799 llvm-svn: 343088
* [cmake] fix a typo in llvm_config macroPavel Labath2018-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: The macro parses out the USE_SHARED option out of the argument list, but then ignores it and accesses the variable with the same name instead. It seems the intention here was to check the argument value. Technically, this is NFC, because the only in-tree usage (add_llvm_executable) of USE_SHARED sets both the variable and the argument when calling llvm_config, but it makes the usage of this macro for out-of-tree users more sensible. Reviewers: mgorny, beanz Reviewed By: mgorny Subscribers: foutrelis, llvm-commits Differential Revision: https://reviews.llvm.org/D44420 llvm-svn: 334082
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [cmake] Modernize some conditionals. NFCShoaib Meenai2017-12-051-2/+2
| | | | | | | | | | | | | The "x${...}" form was a workaround for CMake versions prior to 3.1, where the if command would interpret arguments as variables even when quoted [1]. We can drop the workaround now that our minimum CMake version is 3.4. [1] https://cmake.org/cmake/help/v3.1/policy/CMP0054.html Differential Revision: https://reviews.llvm.org/D40744 llvm-svn: 319723
* [CMake][LLVM] Remove duplicated library mask. Broken clang linking against ↵Oleg Ranevskyy2017-08-101-6/+3
| | | | | | | | | | | | | | | | | | | clangShared Summary: The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LLVMARMInfo, LLVMAArch4Info, etc appearing twice in `extract_symbols.py` command line while building `clangShared`. `Extract_symbols.py` does not work well in such a case and completely ignores the symbols from the duplicated libraries. Thus, the LLVM(...)Info symbols do not get exported from `clangShared` and linking clang against it fails with unresolved dependencies. Seems to be a mere copy-paste mistake. Reviewers: beanz, chapuni Reviewed By: chapuni Subscribers: chapuni, aemerson, mgorny, kristof.beyls, llvm-commits, asl Differential Revision: https://reviews.llvm.org/D36119 llvm-svn: 310590
* [CMake] Fix `is_llvm_target_library` and support out-of-order componentsChris Bieneman2017-02-081-11/+73
| | | | | | | | | | | | Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
* Avoid linking LLVM component libraries with libLLVMAndrew Wilkins2016-02-121-1/+10
| | | | | | | | | | | 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
* [cmake] rework LLVM_LINK_LLVM_DYLIB option handlingAndrew Wilkins2015-09-051-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add targets to cmake for specific target components.Pete Cooper2015-04-201-0/+35
| | | | | | | | | | | | 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. llvm-svn: 235324
* Raising minimum required CMake version to 2.8.12.2.Chris Bieneman2015-03-231-2/+2
| | | | | | This commit is in reference to the llvm-dev thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083672.html llvm-svn: 233008
* Revert "Raising minimum required CMake version to 2.8.12.2."Tobias Grosser2015-02-241-2/+2
| | | | | | | | | | | This reverts commit r230062. Debian stable (wheezy) ships still with cmake 2.8.9. The commit broke my LLVM/Polly buildbot, to my knowledge our only Linux+cmake buildbot. llvm-svn: 230343
* Revert "Revert "Raising minimum required CMake version to 2.8.12.2.""Chad Rosier2015-02-231-2/+2
| | | | | | This reverts commit r230240, which was an accidental commit. llvm-svn: 230246
* Revert "Raising minimum required CMake version to 2.8.12.2."Chad Rosier2015-02-231-2/+2
| | | | | | This reverts commit 247aed4710e8befde76da42b27313661dea7cf66. llvm-svn: 230240
* Raising minimum required CMake version to 2.8.12.2.Chris Bieneman2015-02-201-2/+2
| | | | llvm-svn: 230062
* [cmake] Unbreak LLVM-Config.cmake / llvm_expand_dependencies.Peter Zotov2014-12-181-20/+30
| | | | | | | | | | | | | The algorithm for sorting libraries in topological order, as previously implemented, had a few issues: * It didn't make any sense. * It didn't actually sort libraries in topological order. * It hung on some inputs, e.g. "LLVMipo". This commit replaces the old algorithm with a straightforward port from llvm-config.cpp. llvm-svn: 224554
* Fix misinterpretation of CMake rule found by a CMake warning (related to ↵Richard Smith2014-09-261-2/+2
| | | | | | | | | | | | | | | | | | CMP0054). lldb sets the variable SHARED_LIBRARY to 1, which breaks this conditional, because older versions of CMake interpret if ("${t}" STREQUAL "SHARED_LIBRARY") as meaning if ("${t}" STREQUAL "1") in this case. Change the conditional so it does the right thing with both old and new CMakes. llvm-svn: 218542
* Emit a warning if llvm_map_components_to_libraries() is used noting that itsDan Liew2014-07-281-1/+3
| | | | | | | | | | use is deprecated in favour of llvm_map_components_to_libnames() Although message(DEPRECATION "msg") would probably be a better fit this does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are both off, which is the default. llvm-svn: 214078
* [CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo ↵NAKAMURA Takumi2014-07-141-0/+9
| | | | | | as well, when target names or "nativecodegen" are specified. llvm-svn: 212921
* [CMake] Use target_link_libraries(INTERFACE|PRIVATE) on CMake-2.8.12 to ↵NAKAMURA Takumi2014-02-261-1/+9
| | | | | | | | | | | | | | | | | | increase opportunity for parallel build. 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
* Simplify linking to system librariesNAKAMURA Takumi2014-02-231-30/+5
| | | | | | | | | | | | | | | | | | | | | | | | | The LLVMSupport library implementation consolidates all dependencies on system libraries. Move the logic gathering system libraries out of 'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'. Use the target_link_libraries() command there to tell CMake about the link dependencies of the LLVMSupport implementation. CMake will automatically propagate this to all targets that link LLVMSupport directly or indirectly. We still need to build knowledge of system library dependencies into 'llvm-config'. Store the list of libraries needed in a property on LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it from there. Drop all calls to 'link_system_libs' and 'get_system_libs' from our CMake code. Replace their implementations with a warning that explains the calls are no longer necessary. Also drop from 'LLVMConfig.cmake' the HAVE_* and related variables that were published there only to allow 'get_system_libs' to run outside our build process. Contributed by Brad King. llvm-svn: 201969
* Teach LLVM-Config to use logical target names (2/2)NAKAMURA Takumi2014-02-211-4/+7
| | | | | | | | | | | | | The module still needs to collect the list of all available libraries in order to satisfy the 'all' component. Provide this in the package configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS variable. (A variable is scoped better than a global property.) Since this won't be set for our own build, fall back to looking up the LLVM_LIBS property to get the value when it is not set. Contributed by Brad King. llvm-svn: 201853
* Teach LLVM-Config to use logical target names (1/2)NAKAMURA Takumi2014-02-211-15/+7
| | | | | | | | | | | LLVM library names are now available as logical CMake targets both to our own build and to application CMake code. Replace use of 'list(FIND)' with a simple 'if(TARGET)' to determine whether a library is available. Contributed by Brad King. llvm-svn: 201852
* [CMake] Re-apply r200765, "Get rid of llvm_config() to expand dependencies."NAKAMURA Takumi2014-02-101-7/+1
| | | | | | | | CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements. Configuration time may be reduced by a few seconds. llvm-svn: 201062
* [CMake] Deliberately get all LLVM library dependencies for standalone builds.Jordan Rose2014-02-051-1/+7
| | | | | | | | CMake won't expand the dependency graph for us if the dependencies are in another project, which leads to link errors in the standalone build. This is a refinement of r200765. llvm-svn: 200812
* [CMake] Get rid of llvm_config() to expand dependencies.NAKAMURA Takumi2014-02-041-1/+1
| | | | | | | | CMake's target_link_libraries() will manage dependencies. Configuration time may be reduced by a few seconds. llvm-svn: 200765
* [CMake] LLVM-Config.cmake: Split explicit_map_components_to_libraries and ↵NAKAMURA Takumi2014-02-041-3/+16
| | | | | | introduce llvm_map_components_to_libnames and llvm_expand_dependencies. llvm-svn: 200764
* [CMake] Untabify.NAKAMURA Takumi2014-02-021-13/+13
| | | | llvm-svn: 200644
* 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
* Target a minimal terminfo library rather than necessarily a full cursesChandler Carruth2013-08-121-7/+3
| | | | | | | | | | | | | | | | | | | | library for color support detection. This still will use a curses library if that is all we have available on the system. This change tries to use a smaller subset of the curses library, specifically the subset that is on some systems split off into a separate library. For example, if you install ncurses configured --with-tinfo, a 'libtinfo' is install that provides just the terminfo querying functionality. That library is now used instead of curses when it is available. This happens to fix a build error on systems with that library because when we tried to link ncurses into the binary, we didn't pull tinfo in as well. =] It should also provide an easy path for supporting the NetBSD libterminfo library, but as I don't have access to a NetBSD system I'm leaving adding that support to those folks. llvm-svn: 188160
* Add support for linking against a curses library when available andChandler Carruth2013-08-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | using it to detect whether or not a terminal supports colors. This replaces a particularly egregious hack that merely compared the TERM environment variable to "dumb". That doesn't really translate to a reasonable experience for users that have actually ensured their terminal's capabilities are accurately reflected. This makes testing a terminal for color support somewhat more expensive, but it is called very rarely anyways. The important fast path when the output is being piped somewhere is already in place. The global lock may seem excessive, but the spec for calling into curses is *terrible*. The whole library is terrible, and I spent quite a bit of time looking for a better way of doing this before convincing myself that this was the fundamentally correct way to behave. The damage of the curses library is very narrowly confined, and we continue to use raw escape codes for actually manipulating the colors which is a much sane system than directly using curses here (IMO). If this causes trouble for folks, please let me know. I've tested it on Linux and will watch the bots carefully. I've also worked to account for the variances of curses interfaces that I could finde documentation for, but that may not have been sufficient. llvm-svn: 187874
* Add basic zlib support to LLVM. This would allow to use ↵Alexey Samsonov2013-04-231-0/+3
| | | | | | compression/uncompression in selected LLVM tools. llvm-svn: 180083
* Remove the executable bit on cmake filesSylvestre Ledru2013-04-211-0/+0
| | | | llvm-svn: 179976
* Add time getters to the process interface for requesting the elapsedChandler Carruth2013-01-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wall time, user time, and system time since a process started. For walltime, we currently use TimeValue's interface and a global initializer to compute a close approximation of total process runtime. For user time, this adds support for an somewhat more precise timing mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock selected. For system time, we have to do a full getrusage call to extract the system time from the OS. This is expensive but unavoidable. In passing, clean up the implementation of the old APIs and fix some latent bugs in the Windows code. This might have manifested on Windows ARM systems or other systems with strange 64-bit integer behavior. The old API for this both user time and system time simultaneously from a single getrusage call. While this results in fewer system calls, it also results in a lower precision user time and if only user time is desired, it introduces a higher overhead. It may be worthwhile to switch some of the pass timers to not track system time and directly track user and wall time. The old API also tracked walltime in a confusing way -- it just set it to the current walltime rather than providing any measure of wall time since the process started the way buth user and system time are tracked. The new API is more consistent here. The plan is to eventually implement these methods for a *child* process by using the wait3(2) system call to populate an rusage struct representing the whole subprocess execution. That way, after waiting on a child process its stats will become accurate and cheap to query. llvm-svn: 171551
* build/cmake: Switch to using llvm-build computed dependencies.Daniel Dunbar2011-11-291-1/+1
| | | | | | | | - I verified locally that the current dependency lists are identical. - This makes add_llvm_library_dependencies() a no-op. I'll remove it once this change passes the bots. llvm-svn: 145355
* Make my attempt to build up global deps variables actually utilizeChandler Carruth2011-07-291-8/+9
| | | | | | | | globally scoped constructs. Also, round-trip these dependencies through the LLVMConfig.cmake.in file thata is used by CMake-based clients of "installed" (or built) LLVM trees. llvm-svn: 136543
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-27/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-1/+1
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Rename LLVMConfig.cmake to LLVM-Config.cmake. The *Config.cmake namingOscar Fuentes2011-04-051-0/+203
scheme is used by the functionality related to find_package. llvm-svn: 128889
OpenPOWER on IntegriCloud