summaryrefslogtreecommitdiffstats
path: root/lldb/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* [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] Add first CMake cache filesStefan Granitz2019-05-172-0/+30
| | | | | | | | | | | | | | | | | | | | | | | Summary: CMake cache scripts pre-populate the CMakeCache in a build directory with commonly used settings. The CMake invocation from D61952 could look like this: ``` cmake -G Ninja -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-osx.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" ../llvm-project/llvm ``` Options specified on the command line will override options in the cache files (as long as caches don't use `FORCE`). What do you think? (This is a first proposal and not set in stone.) Reviewers: xiaobai, compnerd, JDevlieghere, aprantl, labath Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D61956 llvm-svn: 361069
* [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
* [CMake] Set LLVM_DEFAULT_EXTERNAL_LIT in standalone build correctly on windowsAlex Langford2019-03-181-1/+6
| | | | | | | LLVM installed llvm-lit with a .py suffix on windows. Let's match that behavior here. llvm-svn: 356412
* Fix a typo in FindLibEdit.cmakePavel Labath2019-03-151-1/+1
| | | | | | | | | The package name is LibEdit, so we should use that name in the call to find_package_handle_standard_args. Failing to do so results in the standard_args (such as the one telling us whether REQUIRED was used in the find_package invocation) not being handled. llvm-svn: 356263
* Revert "[CMake] Avoid clang-tablegen-targets dependency when building sphinx ↵Stefan Granitz2019-03-121-1/+1
| | | | | | | | | docs (experimental)" This reverts commit 511066858d44101703d61eded9abf8caff0f9fe0. This turned out unnecessary to fix the bot. llvm-svn: 355931
* [CMake] Avoid clang-tablegen-targets dependency when building sphinx docs ↵Jonas Devlieghere2019-03-121-1/+1
| | | | | | | | | | | | | (experimental) Proposal to fix bot http://lab.llvm.org:8011/builders/lldb-sphinx-docs/builds/1564/steps/cmake-configure/logs/stdio Patch by: Stefan Gränitz Differential revision: https://reviews.llvm.org/D59232 llvm-svn: 355887
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
* [cmake] Move LLDB_DISABLE_LIBEDIT handling code into a central placePavel Labath2019-02-282-19/+24
| | | | | | | | | | | | | This was previously scattered between the main CMakeLists.txt file and LLDBGenerateConfig.cmake and LLDBConfig.cmake. This caused the some of the code to be executed in incorrect order. Specifically, the check for el_winsertstr was done before libedit_LIBRARIES was computed, and so it always failed on the first run. Moving it the two checks to a central place makes sure this doesn't happen again and improves the overall readability. llvm-svn: 355103
* [CMake] Fix RPATH handling for LLDB.frameworkStefan Granitz2019-02-142-10/+13
| | | | | | | | | | | | | | | | | Summary: Generator expressions are not supported in the `BUILD_RPATH` target property. `BUILD_RPATH` is only supported in 3.8+ https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html `LLDB_FRAMEWORK_INSTALL_DIR` should not overwrite, but rather add an install RPATH (and it should be the first) Reviewers: xiaobai, lanza Reviewed By: xiaobai Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D57989 llvm-svn: 354037
* [lldb] [cmake] Use install directories for LLVM_* variablesMichal Gorny2019-02-131-3/+3
| | | | | | | | | | | | | Restore the previous behavior of using install directories for LLVM_MAIN_INCLUDE_DIR, LLVM_LIBRARY_DIR and LLVM_BINARY_DIR. The update from llvm-config to CMake has changed the values of those values to use LLVM_BUILD_* which is plain wrong and breaks stand-alone builds. Instead, use the CMake counterparts of the values returned by llvm-config. Differential Revision: https://reviews.llvm.org/D57995 llvm-svn: 353925
* [CMake] Accept entitlements for code signing in add_lldb_library()Stefan Granitz2019-01-301-3/+13
| | | | | | | | | | | | | | | | | Summary: D57334 added entitlements support in `add_llvm_library()` so we can use it for library targets in LLDB. Additionally this patch fixes the way that the entitlements argument is passed on from `add_lldb_executable()` to `add_llvm_executable()`. We still need the explicit parsing and passing on of single- and multi-value arguments as long as we are on CMake < 3.7 (due to bug https://gitlab.kitware.com/cmake/cmake/merge_requests/133). Reviewers: beanz, JDevlieghere, aprantl Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D57378 llvm-svn: 352629
* [CMake] Dump LLDB.framework tools at configuration timeStefan Granitz2019-01-281-0/+1
| | | | llvm-svn: 352387
* [CMake] Quick-Fix targets don't exist when building against LLVM ↵Stefan Granitz2019-01-281-1/+3
| | | | | | | | | | install-tree with LLDB_INCLUDE_TESTS=ON The issue came up during release testing for LLVM 8: https://bugs.llvm.org/show_bug.cgi?id=40443 Differential Revision: https://reviews.llvm.org/D57233 llvm-svn: 352382
* [cmake] Fix get_llvm_lit_path() to respect LLVM_EXTERNAL_LIT alwaysMichal Gorny2019-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT, and require the fallback to be defined explicitly as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone after r346888. The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache variable and an optional pre-definition of default value from caller (e.g. libcxx). It included a hack to make this work by assigning the value back and forth but it was fragile and stopped working in libcxx. The new logic is simpler and more transparent. Default value is provided in a separate variable, and used only when user-specified variable is empty (i.e. not overriden). Differential Revision: https://reviews.llvm.org/D57282 llvm-svn: 352374
* [CMake] Use llvm-tblgen from NATIVE LLVM build when cross-compilingAlex Langford2019-01-251-2/+25
| | | | | | | | | | | | | | Summary: When cross-compiling LLDB, we want to use llvm-tblgen built for the host, not the target. Reviewers: compnerd, sgraenitz Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D57194 llvm-svn: 352235
* [CMake] Remove duplicated cache variable. NFC.Alex Langford2019-01-241-2/+0
| | | | llvm-svn: 352078
* [CMake] Get back some variables used in AddLLVM.cmakeStefan Granitz2019-01-241-0/+5
| | | | | | This fixes 'gtest/gtest.h' file not found when building unit tests after r351863. llvm-svn: 352058
* [CMake] Fix two details from r351863Stefan Granitz2019-01-221-3/+3
| | | | llvm-svn: 351879
* [CMake] Replace use of llvm-config with LLVM and Clang CMake packagesAlex Langford2019-01-221-77/+20
| | | | | | | | | | | | | | | | | | | | Summary: I did this for two reasons: - Using the CMake packages simplifies building LLDB Standalone. This is for two reasons: 1) We were doing a decent amount of work that is already done in the LLVMConfig.cmake that we want to import, 2) We had to do some manual work to call llvm-config, parse its output, and populate variables that the build system uses. - As far as I understand, using llvm-config makes it difficult if not impossible to cross-compile LLDB standalone. Reviewers: sgraenitz, labath, zturner, JDevlieghere, davide, aprantl, stella.stamenova Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56531 llvm-svn: 351863
* [CMake] Turn LLDB_FRAMEWORK_TOOLS into STRING to allow overrides from cache ↵Stefan Granitz2019-01-221-1/+1
| | | | | | files llvm-svn: 351830
* [CMake] Include tests by default also in standalone buildsStefan Granitz2019-01-111-0/+1
| | | | | | In-tree builds include tests by default. Standalone builds should behave the same. llvm-svn: 350945
* [CMake] Remove dead code and outdated commentsStefan Granitz2019-01-111-1/+0
| | | | | | | | | | | | | | Summary: All of these changes are NOPs. Reviewers: stella.stamenova, labath, JDevlieghere Reviewed By: stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56609 llvm-svn: 350937
* [CMake] In standalone builds, LLVM_BINARY_DIR should point to LLVM's binary ↵Stefan Granitz2019-01-091-3/+1
| | | | | | | | | | | | | | | | directory Summary: In standalone builds `LLVM_BINARY_DIR` was equal to `LLDB_BINARY_DIR` so far. This is counterintuitive and invalidated the values of `LLDB_DEFAULT_TEST_DSYMUTIL/FILECHECK/COMPILER` etc. Reviewers: zturner, labath, clayborg, JDevlieghere, stella.stamenova, serge-sans-paille Reviewed By: labath Subscribers: mgorny, friss, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56443 llvm-svn: 350738
* [CMake] Revised RPATH handlingStefan Granitz2019-01-042-4/+55
| | | | | | | | | | | | | | | | | | | | | | | Summary: If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling. * In the build-tree, tools use the absolute path to the framework's actual output location. * In the install-tree, tools get a list of RPATHs to look for the framework when deployed. `LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree. If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree). If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree. For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks". Reviewers: xiaobai, JDevlieghere, aprantl, clayborg Reviewed By: JDevlieghere Subscribers: ki.stfu, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55330 llvm-svn: 350392
* [CMake] Revised LLDB.framework buildsStefan Granitz2019-01-043-92/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements. Options: * `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree) * `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree * `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`) * `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets) Other changes: * clean up `add_lldb_executable()` * include `LLDBFramework.cmake` from `source/API/CMakeLists.txt` * use `*.plist.in` files, which are typical for CMake and independent from Xcode * add clang headers to the framework bundle Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath Reviewed By: aprantl Subscribers: friss, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55328 llvm-svn: 350391
* [CMake] Move debugserver options to separate debugserverConfig.cmakeStefan Granitz2019-01-041-0/+3
| | | | | | | | | | | | | | | Summary: One place for debugserver options, analog to LLDBConfig for LLDB options (see D55317). It was discussed in earlier reviews already, e.g. D55013. Reviewers: JDevlieghere, aprantl, xiaobai Reviewed By: aprantl, xiaobai Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55320 llvm-svn: 350390
* [CMake] Aggregate options for LLDB in LLDBConfig.cmakeStefan Granitz2019-01-041-21/+33
| | | | | | | | | | | | | | Summary: In preparation for LLDB.framework changes, collect options for LLDB in LLDBConfig.cmake (used for both, standalone and in-tree builds of LLDB). Reviewers: JDevlieghere, aprantl, xiaobai Reviewed By: aprantl Subscribers: srhines, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55317 llvm-svn: 350389
* [CMake] Streamline code signing for debugserver #2Stefan Granitz2019-01-042-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Major fixes after D54476 (use Diff1 as base for comparison to see only recent changes): * In standalone builds target directory for debugserver must be LLDB's bin, not LLVM's bin * Default identity for code signing must not force-override LLVM_CODESIGNING_IDENTITY globally We have a lot of cases, make them explicit: * ID used for code signing (debugserver and in tests): ** `LLDB_CODESIGN_IDENTITY` if set explicitly, or otherwise ** `LLVM_CODESIGNING_IDENTITY` if set explicitly, or otherwise ** `lldb_codesign` as the default * On Darwin we have a debugserver target that: * On other systems, the debugserver target is not defined, which is equivalent to **[3A]** Common configurations on Darwin: * **[1A]** `cmake -GNinja ../llvm` builds debugserver from source and signs with `lldb_codesign`, no code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//) * **[1A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_CODESIGN_IDENTITY=lldb_codesign ../llvm` builds debugserver from source and signs with `lldb_codesign`, ad-hoc code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//) * **[2A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_USE_SYSTEM_DEBUGSERVER=ON ../llvm` copies debugserver from system, ad-hoc code signing for other binaries (prints status: //Copy system debugserver from: /path/to/system/debugserver//) * **[2B]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- ../llvm` same, but prints additional warning: //Cannot code sign debugserver with identity '-'. Will fall back to system's debugserver. Pass -DLLDB_CODESIGN_IDENTITY=lldb_codesign to override the LLVM value for debugserver.// * **[3A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_NO_DEBUGSERVER=ON ../llvm` debugserver not available (prints status: //lldb debugserver will not be available)// Reviewers: JDevlieghere, beanz, davide, vsk, aprantl, labath Reviewed By: JDevlieghere, labath Subscribers: mgorny, #lldb, lldb-commits Differential Revision: https://reviews.llvm.org/D55013 llvm-svn: 350388
* [cmake] Suppress 'warning C4201: nonstandard extension used: nameless ↵Stella Stamenova2018-12-211-0/+1
| | | | | | | | struct/union' on Windows This warning comes up in the ObjC language plugin because of the use of nameless structs. This change suppresses the warning. llvm-svn: 349977
* Reenable FindLibXml2 on Windows and confirm its at least 2.8 or newerNathan Lanza2018-12-181-11/+5
| | | | | | | | | | | | | | | | | | | | | Summary: GnuWin32 installs libxml2 2.4. This isn't recent enough for lldb's usage and thus the build fails. Searching for libxml2 was disabled due to this build failure. However, the gdb-remote plugin requires libxml2 to parse various gdb-remote protocol packets. Thus check and confirm that the libxml2 version is at least 2.8 and disable it if not. Reviewers: compnerd, zturner Reviewed By: compnerd Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D55583 llvm-svn: 349538
* [CMake] Fix side-effect from LLDB_VERSION change in r346668 for ↵Stefan Granitz2018-12-051-1/+1
| | | | | | framework-enabled builds llvm-svn: 348360
* Make standalone build find tabelgenJonas Devlieghere2018-11-281-0/+1
| | | | | | | The standalone build couldn't find tablegen because we didn't include it. This patch rectifies that. llvm-svn: 347814
* Revert "[CMake] Streamline code signing for debugserver and pass ↵Davide Italiano2018-11-271-2/+2
| | | | | | | | entitlements to extended llvm_codesign" It breaks the lldb cmake bots. llvm-svn: 347619
* [CMake] Streamline code signing for debugserver and pass entitlements to ↵Stefan Granitz2018-11-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | extended llvm_codesign Summary: Use llvm_codesign to sign debugserver with entitlements. Set global LLVM_CODESIGNING_IDENTITY from LLDB_CODESIGN_IDENTITY (if given). Pass through ENTITLEMENTS from add_lldb_executable to add_llvm_executable. Handle reconfigurations correctly. We have a lot of cases, make them explicit: (1) build and sign debugserver, if all conditions apply: * LLDB_NO_DEBUGSERVER=OFF (default) * On Darwin: LLDB_USE_SYSTEM_DEBUGSERVER=OFF (default) * On Darwin: LLVM_CODESIGNING_IDENTITY == lldb_codesign (2) use system debugserver, if on Darwin and any of: * LLDB_USE_SYSTEM_DEBUGSERVER=ON and found on system (explicit case) * LLVM_CODESIGNING_IDENTITY != lldb_codesign and found on system (fallback case) (3) debugserver will not be available, in case of: * LLDB_NO_DEBUGSERVER=ON * On Darwin: LLVM_CODESIGNING_IDENTITY != lldb_codesign and not found on system (4) error state, in case of: * LLDB_USE_SYSTEM_DEBUGSERVER=ON and not found on system * LLDB_USE_SYSTEM_DEBUGSERVER=ON and LLDB_NO_DEBUGSERVER=ON Reviewers: xiaobai, beanz, vsk, JDevlieghere Subscribers: mgorny, lldb-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D54476 llvm-svn: 347305
* [CMake] Allow version overrides with -DLLDB_VERSION_MAJOR/MINOR/PATCH/SUFFIXStefan Granitz2018-11-121-3/+14
| | | | | | | | | | | | | | Summary: This follows the approach in Clang. If no overrides are given, LLDB_VERSION_* is inferred from LLVM_VERSION_*. This mimics the current behaviour (PACKAGE_VERSION itself is generated from LLVM_VERSION_*). For in-tree builds LLVM_VERSION_* will be defined at this point already. For standalone builds, LLDBConfig.cmake is included after LLDBStandalone.cmake which includes LLVMConfig.cmake. Reviewers: labath, xiaobai Subscribers: mgorny, friss, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D54333 llvm-svn: 346668
* [lldb] Fix race condition in framework installationShoaib Meenai2018-10-311-1/+1
| | | | | | | | | | | | | We need the install-liblldb-stripped target to depend on the lldb-framework target in order for the installation to be guaranteed to behave correctly, otherwise it's possible for the lldb-framework and install-liblldb-stripped targets to run in parallel, resulting in temporary or partially processed files being copied into the framework. install-liblldb already depends on lldb-framework for this reason. Differential Revision: https://reviews.llvm.org/D53917 llvm-svn: 345711
* [cmake] Add option to skip building lldb-serverAlex Langford2018-08-231-0/+2
| | | | | | | | | | | | | | | Summary: There is currently a way to skip the debugserver build. See how the CMake variables SKIP_DEBUGSERVER and LLDB_CODESIGN_IDENTITY are used if you're interested in that. This allows us to skip building lldb-server as well. There is another debug server called ds2 that can be used with LLDB. If you choose to use ds2, this flag is very useful because it can cut down the build time of LLDB. Differential Revision: https://reviews.llvm.org/D49282 llvm-svn: 340560
* Add include directory for libxml on macOSStephane Sezer2018-08-221-2/+1
| | | | | | | | | | | | | | | | | Summary: Builds fail because libxml/xmlreader.h isn't found. Adding the include directory to the include list fixes the issue. This is what we already do on non-macOS platforms in the same file. Reviewers: clayborg, xiaobai, lanza Reviewed By: clayborg, lanza Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D50918 llvm-svn: 340460
* Introduce install-lldb-framework targetAlex Langford2018-08-012-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, I thought that install-liblldb would fail because CMake had a bug related to installing frameworks. In actuality, I misunderstood the semantics of `add_custom_target`: the DEPENDS option refers to specific files, not targets. Therefore `install-liblldb` should rely on the actual liblldb getting generated rather than the target. This means that the previous patch I committed (to stop relying on CMake's framework support) is no longer needed and has been reverted. Using CMake's framework support greatly simplifies the implementation. `install-lldb-framework` (and the stripped variant) is as simple as depending on `install-liblldb` because CMake knows that liblldb was built as a framework and will install the whole framework for you. The stripped variant will depend on the stripped variants of individual tools only to ensure they actually are stripped as well. Reviewers: labath, sas Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50038 llvm-svn: 338594
* Revert "Stop building liblldb with CMake's framework functionality"Alex Langford2018-07-273-32/+16
| | | | | | | | | | This reverts r338154. This change is actually unnecessary, as the CMake bug I referred to was actually not a bug but a misunderstanding of CMake. Original Differential Revision: https://reviews.llvm.org/D49888 llvm-svn: 338178
OpenPOWER on IntegriCloud