summaryrefslogtreecommitdiffstats
path: root/lldb/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
...
* Enable lldb-server on WindowsAaron Smith2019-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit contains three small changes to enable lldb-server on Windows. - Add lldb-server for Windows to the build - Disable pty redirection on Windows for the initial lldb-server bring up - Add a support to get the parent pid for a process on Windows - Ifdef some signals which aren't supported on Windows Thanks to Hui Huang for the help with this patch! Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61686 llvm-svn: 368774
* Remove xcode-specific Config.hPavel Labath2019-08-081-2/+1
| | | | | | | | | | | | | | | | | | Summary: Now that the xcode project is removed, we no longer need/use the hand-maintained Config.h file, as everything is configured through cmake. This patch deletes that file and reverts some of the changes from r300372, which were made to support this use case. Reviewers: sgraenitz, beanz Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D65862 llvm-svn: 368266
* [lldb][NFC] Fix typo in 368066Stefan Granitz2019-08-071-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368143
* Detect HAVE_SYS_TYPES_H in lldbHaibo Huang2019-08-071-0/+1
| | | | | | | | | | | | | | | | Summary: After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in Platform.h, or anywhere else in lldb. This change fixes that. Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65822 llvm-svn: 368125
* [lldb][CMake] Generating Xcode projectsStefan Granitz2019-08-061-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Print a warning if the wrong cache script is used when generating a Xcode project, because it's too easy to confuse with Apple-lldb-macOS.cmake ``` When building with Xcode, we recommend using the corresponding cache script. If this was a mistake, clean your build directory and re-run CMake with: -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject ``` Also set the generator inside the cache script. Reviewers: JDevlieghere, jingham, clayborg Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368066
* [CMake] Move project() call to main CMake fileHaibo Huang2019-07-291-2/+0
| | | | | | | | | | | | | | | Summary: The main CMake file don't have a project() call. In this case, cmake will run a dummy project(Project ) at the very beginning. Even before cmake_minimum_required. And a series of compiler detections will be triggered. This is problematic if we depends on some policy to be set. E.g. CMP0056. try_compile will fail before we have a chance to do anything. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65362 llvm-svn: 367273
* [CMake] Print the correct variablesJonas Devlieghere2019-07-261-1/+1
| | | | | | | | This didn't get updated after we decided to set PYTHON_MAJOR_VERSION and PYTHON_MINOR_VERSION in find_python_libs_windows, instead of parsing the variables ourselves. llvm-svn: 367153
* [CMake] Fix find_python_libs_windowsJonas Devlieghere2019-07-261-0/+1
| | | | | | | Exporting PYTHON_INCLUDE_DIR to the Python scope somehow got lost in my last change. Add it back again. This should fix the Windows bot! llvm-svn: 367127
* [CMake] Print Python version on WindowsJonas Devlieghere2019-07-261-2/+2
| | | | | | Trying to figure out what's causing the Windows bot to fail. llvm-svn: 367125
* [CMake] Loosen Python version check and ignore patch versionJonas Devlieghere2019-07-261-10/+36
| | | | | | | | | Some versions of macOS report a different patch version for the system provided interpreter and libraries. Differential revision: https://reviews.llvm.org/D65230 llvm-svn: 367115
* [lldb][CMake] Fix framework-enabled build detail for XcodeStefan Granitz2019-07-251-1/+1
| | | | | | If debugserver or any other framework tool gets built first, its post-build copy operation was using 'Resources' as the file name instead of the destination directory. It was not a problem with Ninja, because here the framework structure was alreaady created at configuration time. With this fix, both generators are happy. llvm-svn: 367005
* build: allow the user to specify `llvm-tblgen`Saleem Abdulrasool2019-07-201-23/+27
| | | | | | | | | | | | This follows the same pattern as Clang and permits the user to specify the tablegen to use via `-DLLVM_TABLEGEN=`. This allows for cross-compiling LLDB for a foreign target (e.g. Windows ARM64 on Windows X64). The LLVM dependency for LLDB in that case must be a Windows ARM64 build which cannot cross-compile llvm-tblgen due to the way that Visual Studio works. Instead, permit the user to have a separate tablegen build which can be used during the build. llvm-svn: 366639
* [CMake] Align debugserver with lldb-server on DarwinStefan Granitz2019-07-201-5/+5
| | | | | | | | | | | | | | | | Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here. Reviewers: xiaobai, JDevlieghere, davide Reviewed By: xiaobai, JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64994 llvm-svn: 366631
* [CMake] Polish folders in generated Xcode projectStefan Granitz2019-07-182-1/+6
| | | | | | | | | | | | | | Summary: Group plugins by subfolder. Move liblldb-resource-headers to `lldb misc`. Avoid install-distribution related targets in IDE-enabled builds. Reviewers: jingham, mib, stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64865 llvm-svn: 366459
* [CMake] Always build debugserver on Darwin and allow tests to use the ↵Stefan Granitz2019-07-182-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | system's one Summary: We can always build debugserver, but we can't always sign it to be useable for testing. `LLDB_USE_SYSTEM_DEBUGSERVER` should only tell whether or not the system debugserver should be used for testing. The old behavior complicated the logic around debugserver a lot. The new logic sorts out most of it. Please note that this patch is in early stage and needs some more testing. It should not affect platfroms other than Darwin. It builds on Davide's approach to validate the code-signing identity at configuration time. What do you think? Reviewers: xiaobai, JDevlieghere, davide, compnerd, friss, labath, mgorny, jasonmolenda Reviewed By: JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64806 llvm-svn: 366433
* [NFC] Clarify a Cmake status message regarding Python on LLDBConfigAdrian McCarthy2019-07-171-1/+1
| | | | llvm-svn: 366383
* [CMake] Remove duplicated logic to find Python when doing a standalone buildJonas Devlieghere2019-07-171-12/+0
| | | | | | | | | | | I'm pretty sure there's no need to have this logic living in LLDBStandalone. It doesn't appear anything in LLVM depends on this, and We always go through LLDBConfig.cmake which has the canonical way to find the Python libs and interpreter for LLDB. Differential revision: https://reviews.llvm.org/D64821 llvm-svn: 366363
* [CMake] Use LLVM_DIR and Clang_DIR for standalone builds.Jonas Devlieghere2019-07-171-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing a standalone build, without setting LLDB_PATH_TO_LLVM_BUILD or LLDB_PATH_TO_CLANG_BUILD, you get the following error. ``` CMake Error at cmake/modules/LLDBStandalone.cmake:23 (find_package): Could not find a package configuration file provided by "LLVM" with any of the following names: LLVMConfig.cmake llvm-config.cmake Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set "LLVM_DIR" to a directory containing one of the above files. If "LLVM" provides a separate development package or SDK, be sure it has been installed. ``` This suggests setting LLVM_DIR to LLVM's install directory. However, LLDBStandalone.cmake takes LLDB_PATH_TO_LLVM_BUILD as its hint. As someone who isn't familiar with the standalone process, this is rather confusing. This patch removes LLDB_PATH_TO_LLVM_BUILD and LLDB_PATH_TO_CLANG_BUILD and instead use LLVM_DIR and Clang_DIR respectively. Differential revision: https://reviews.llvm.org/D64823 llvm-svn: 366362
* [CMake] Avoid liblldb genex when figuring out the copy destination for ↵Stefan Granitz2019-07-171-1/+2
| | | | | | | | framework tools This genex created an order-only dependency to liblldb for every framework tool. It reduced build throughput in the first half of the compilation and pulled in unnecessary build units, e.g. debugserver required ~900 build units. With this change debugserver is (again) down at 52 build units! llvm-svn: 366350
* [CMake] Move standalone check so we don't have to reconfigure LLDBJonas Devlieghere2019-07-171-99/+96
| | | | | | | | | | | | | By moving the standalone check into the main CMake file, the whole file is ignored in a regular (non-standalone) build. This means that you can make changes to LLDBStandalone.cmake without having to reconfigure a build in a different directory. This matters when you share one source repository with different build directories (e.g. release-assert, debug, standalone). Differential revision: https://reviews.llvm.org/D64824 llvm-svn: 366346
* Don't require python exe and lib versions to match while crosscompilingNathan Lanza2019-07-161-1/+2
| | | | | | | | | | | | | | Summary: While cross compiling, the python executable is used to run a handful of scripts while the libraries are linked and headers are included. Theoretically it's possible for the versions to match completely, but requiring the build to match 2.7.10 to 2.7.15 is unnecessary. Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64822 llvm-svn: 366285
* Fix LLDB Windows build Python version logic after r366243Reid Kleckner2019-07-161-0/+1
| | | | llvm-svn: 366247
* [CMake] Fail when Python interpreter doesn't match Python libraries versionJonas Devlieghere2019-07-161-3/+6
| | | | | | | | | | | | | | Because of how CMake finds the Python libraries and interpreter, it's possible to end up with a discrepancy between the two. For example, you'd end up using a Python 3 interpreter to run the test suite while LLDB was built and linked against Python 2. This patch adds a fatal error to CMake so we find out at configuration time, instead of finding out at test time. Differential revision: https://reviews.llvm.org/D64812 llvm-svn: 366243
* Make Python version setting actually effectiveJonas Devlieghere2019-07-131-1/+1
| | | | | | | | | | | This needs to be outside the if to actually work. Also, this adjusts the list of versions to match LLVM. Patch by: Christian Biesinger Differential revision: https://reviews.llvm.org/D64578 llvm-svn: 365988
* [lldb] Let table gen create command option initializers.Raphael Isemann2019-07-121-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908
* Add Python 3.6 and 3.7 to the version listNico Weber2019-07-101-1/+1
| | | | | | | | | | Python 3.6 and 3.7 have been released. Differential Revision: https://reviews.llvm.org/D64444 Patch from Christian Biesinger <cbiesinger@google.com>! llvm-svn: 365688
* [CMake][NFC] Remove dead code lldb_append_link_flags() from AddLLDB.cmakeStefan Granitz2019-07-101-16/+0
| | | | llvm-svn: 365651
* [CMake][NFC] Polish comments in AddLLDB.cmakeStefan Granitz2019-07-101-2/+6
| | | | llvm-svn: 365650
* [CMake] `install-distribution` for LLDB on DarwinStefan Granitz2019-07-103-47/+102
| | | | | | | | | | | | | | | | | | | | | Summary: There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time. LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally. Please let me know what you think, while I run a few more tests and add remarks+documentation. Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny Reviewed By: xiaobai, JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64408 llvm-svn: 365617
* [CMake] Distribution builds for LLDB standaloneStefan Granitz2019-07-101-0/+1
| | | | | | | | | | | | | | | | | | Summary: Enable `distribution` and `install-distribution` targets in LLDB standalone and pre-populate the cache accordingly on macOS. Documentation for distribution builds is here: https://llvm.org/docs/BuildingADistribution.html Reviewers: xiaobai, mgorny, JDevlieghere, davide, compnerd Reviewed By: xiaobai, JDevlieghere Subscribers: lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64399 llvm-svn: 365616
* [CMake] Remove extra lldb-framework targetStefan Granitz2019-07-101-10/+6
| | | | | | | | | | | | | | | | Summary: The custom lldb-framework target was meant to encapsulate all build steps that LLDB.framework needs on top of the ordinaly liblldb. In the end all of it happens in post-build steps, so we can do the same with liblldb and cut down another source of confusion. Reviewers: xiaobai, JDevlieghere Reviewed By: xiaobai, JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D64397 llvm-svn: 365615
* [CMake] Polish a commentStefan Granitz2019-07-091-1/+2
| | | | llvm-svn: 365459
* [CMake] Remove old lldb_setup_framework_rpaths_in_tool()Stefan Granitz2019-07-091-39/+0
| | | | llvm-svn: 365457
* Update cmake build setup so lldb doesn't link against the DebugSymbolsJason Molenda2019-07-021-1/+0
| | | | | | | | framework on macOS, in line with the source/xcode project changes in r364243. <rdar://problem/49458356> llvm-svn: 364979
* Specify log level for CMake messages (less stderr)Stefan Granitz2019-06-192-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Specify message levels in CMake. Prefer STATUS (stdout). As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools, noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step. This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR) instead of the default. * I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations. * Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know. Patch by: Christoph Siedentop Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz Reviewed By: sgraenitz Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits Tags: #sanitizers, #lldb, #llvm Differential Revision: https://reviews.llvm.org/D63370 llvm-svn: 363821
* [CMake] Fix generated Xcode-project ignoring output directory setting for ↵Stefan Granitz2019-06-131-0/+6
| | | | | | | | | LLDB.framework Other generators honor the `LIBRARY_OUTPUT_DIRECTORY` target property, but apparently Xcode doesn't. So we call `set_output_directory()` as `llvm_add_library()` would do and this works. Note that `LIBRARY_OUTPUT_DIRECTORY` is still necessary, because it's used to store and read the target's absolute build directory (while `LLDB_FRAMEWORK_BUILD_DIR` is relative!). llvm-svn: 363280
* [CMake] Add fallbacks for copying clang-resource-headers to LLDB.framework ↵Stefan Granitz2019-06-131-3/+25
| | | | | | in standalone builds llvm-svn: 363271
* NFC: Fix typo in a cmake messageAdrian McCarthy2019-06-071-1/+1
| | | | llvm-svn: 362845
* [CMake] Add configuration dirs as potential locations for llvm-lit and ↵Stefan Granitz2019-06-051-3/+16
| | | | | | | | | | | | | | | | | | | | llvm-tblgen in standalone builds Summary: If the provided LLVM build-tree used a multi-configuration generator like Xcode, `LLVM_TOOLS_BINARY_DIR` will have a generator-specific placeholder to express `CMAKE_CFG_INTDIR`. Thus `llvm-lit` and `llvm-tblgen` won't be found. D62878 exports the actual configuration types so we can fix the path and add them to the search paths for `find_program()`. Reviewers: xiaobai, labath, stella.stamenova Reviewed By: xiaobai, stella.stamenova Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62879 llvm-svn: 362589
* [CMake] LLDB.framework tools handlingStefan Granitz2019-05-293-16/+30
| | | | | | | | | | | | | | | | | | | | Summary: Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach. No function change otherwise. This is a reduced follow-up from the proposal in D61952. Reviewers: xiaobai, compnerd, JDevlieghere Reviewed By: JDevlieghere Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D62472 llvm-svn: 361946
* build: only search for the needed python typeSaleem Abdulrasool2019-05-291-67/+23
| | | | | | | | | | Windows has different types of runtime libraries which are ABI incompatible with one another. This requires that the debug build of lldb link against the debug build of python. Adjust the python search to search for only the required type of python. This permits building a release build of lldb against just the release build of python. llvm-svn: 361915
* [CMake] Folder structure for generated Xcode project to cover more targetsStefan Granitz2019-05-283-2/+14
| | | | llvm-svn: 361799
* [CMake] Correctly reinstate LLDB_CAN_USE_LLDB_SERVERPavel Labath2019-05-141-2/+2
| | | | | | | | | | | | | | | | | r360631 introduced a "syntax error" which meant that cmake was still not honoring the value of LLDB_CAN_USE_LLDB_SERVER variable. The correct syntax for seting an internal cache variable is "set(VAR value CACHE INTERNAL)", but the patch omitted the "CACHE" keyword. The "syntax error" is in quotes because without the CACHE keyword this is still valid syntax for setting the value of LLDB_CAN_USE_LLDB_SERVER to "1 INTERNAL". There doesn't seem to be a need for this to be a cache variable so I'm reverting this variable to a plain one, as it was before r360621. This will hopefully fix the windows build. llvm-svn: 360652
* [CMake] Reinstate LLDB_CAN_USE_LLDB_SERVERJonas Devlieghere2019-05-131-2/+4
| | | | | | | | | | We cannot manipulate the LLDB_TOOL_LLDB_SERVER_BUILD directly from LLDBConfig.cmake because this would set the variable before the option is defined in AddLLVM.cmake. Instead, we need to use the LLDB_CAN_USE_LLDB_SERVER variable to conditionally add the lldb-server subdirectory. This should ensure the variable doesn't get cleared. llvm-svn: 360631
* [CMake] Simplify lldb-server handlingJonas Devlieghere2019-05-131-6/+2
| | | | | | | | | We can piggyback off the existing add_lldb_tool_subdirectory to decide whether or not lldb-server should be built. Differential revision: https://reviews.llvm.org/D61872 llvm-svn: 360621
* [CMake] Fix subtle CMake bugAlex Langford2019-04-291-1/+1
| | | | | | | | CMake specifies that the DEPENDS field of add_custom_target is for files and output of add_custom_command. In order to add a target dependency, add_dependencies should be used. llvm-svn: 359490
* [CMake] Remove Apple-specific version logic.Frederic Riss2019-04-171-11/+0
| | | | | | | | | | | | We were using the LLDB-Info.plist as the canonical holder of the version number, but there is really no good reason to do this. If anything the plist should be generated using the information provided to CMake. For now just remove the logic extracting the version from the plist and rely on LLDB_VERSION_STRING. llvm-svn: 358604
* [tools] Make vscode and lldb-instr optional.Davide Italiano2019-04-161-0/+5
| | | | | | | | | | | | | | | | Summary: Saves some build times, and they're not part of the usual developer workflow. Reviewers: JDevlieghere, friss Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60780 llvm-svn: 358528
* [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone buildsAlex Langford2019-04-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: This line is unnecessary because add_llvm_executable will handle linking the correct LLVM libraries for you. LLDB standalone builds are totally fine without this. In the best case, having this line here is harmless. In the worst case it can cause link issues. If you build lldb-server for android using the standalone build, this line will cause LLVM_LIBRARY_DIR to be the first place you look for libraries. This is an issue because if you built libc++, it will try to link against that one instead of the one from the android NDK. Meanwhile, the LLVM libraries you're linking against were linked against the libc++ from the NDK. Ideally, we would take advantage of the AFTER option for link_directories(), but that was not available in LLDB's minimum supported version of CMake (CMake 3.4.3). Differential Revision: https://reviews.llvm.org/D60180 llvm-svn: 357817
* [Cmake] Unify python variablesJonas Devlieghere2019-03-291-11/+13
| | | | | | | | | | | | | | | | | | | | FindPythonInterp and FindPythonLibs do two things, they set some variables (PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS) and update the cached variables (PYTHON_LIBRARY, PYTHON_INCLUDE_DIR) which are also used to specify a custom python installation. I believe the canonical way to do this is to use the PYTHON_LIBRARIES and PYTHON_INCLUDE_DIRS variables instead of the cached ones. However, since the cached variables are accessible from the cache and GUI, this is a lot less confusing when you're trying to debug why a variable did or didn't get the value you expected. Furthermore, as far as I can tell, the implementation uses the cached variables to set their LIBRARIES/DIRS counterparts. This is also the reason this works today even though we mix-and-match. Differential revision: https://reviews.llvm.org/D59968 llvm-svn: 357282
OpenPOWER on IntegriCloud