summaryrefslogtreecommitdiffstats
path: root/clang-tools-extra/clangd/xpc
Commit message (Collapse)AuthorAgeFilesLines
* Get ClangdXPC.framework building (barely) with CMake's Xcode generatorJordan Rose2019-10-111-2/+2
| | | | | | | | | | | | | | | | | | | The output directories for CMake's Xcode project generator are specific to the configuration, and so looking in CMAKE_LIBRARY_OUTPUT_DIRECTORY isn't going to work. Fortunately, CMake already provides generator expressions to find the output of a given target. I call this "barely" building because the built framework isn't going to respect the configuration; that is, I can't have both Debug and RelWithDebInfo variants of ClangdXPC.framework at the same time like I can with normal library or executable targets. To do that we'd have to put the framework in a configuration-specific output directory or use CMake's native support for frameworks instead. https://reviews.llvm.org/D68846 llvm-svn: 374494
* [clang-tools-extra] [cmake] Link against libclang-cpp whenever possibleMichal Gorny2019-10-041-2/+5
| | | | | | | | | Use clang_target_link_libraries() in order to support linking against libclang-cpp instead of static libraries. Differential Revision: https://reviews.llvm.org/D68448 llvm-svn: 373786
* [clang-tools-extra] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368944
* Support codesigning bundles and forcingChris Bieneman2019-05-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This results in an invalid bundle code signature because the signature only applies to the binaries not the resources. This patch adds two new options to `llvm_codesign` to enable re-signing the library and XPC service as bundles. The `BUNDLE_PATH` option allow specifying an explicit path to codesign, which enables signing bundles which aren't generated using CMake's `FRAMEWORK` or `BUNDLE` target properties. The `FORCE` option allows re-signing binaries that have already been signed. This is required for how clangd exposes the clangd library and tools as both XPC and non-XPC services using the same binary. Reviewers: jkorous, bogner Reviewed By: bogner Subscribers: mgorny, ilya-biryukov, dexonsmith, arphaman, kadircet, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62693 llvm-svn: 362169
* gn build: Add build files for clangd xpc framework codeNico Weber2019-04-032-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a bit of a larger change since this is the first (and as far as I can tell only) place where the LLVM build produces macOS framework bundles. GN has some built-in support for this, so use that. `gn help create_bundle` has a terse description (but it's a bit outdated: `deps` must be `public_deps` and the conditionals in the example in the help aren't quite right on non-iOS). We need a new 'copy_bundle_data' tool, and since we copy the clangd.xpc bundle as bundle_data into ClangdXPC.framework it needs to be able to handle directories in addition to files. GN also insists we have a compile_xcassets tool even though it's not used. I just made that run `false`. Despite GN's support for bundles, we still need to manually create the expected symlink structure in the .framework bundle. Since this code never runs on Windows, it's safe to create the symlinks before the symlink targets exist, so we can just make the bundle depend on the steps that create the symlinks. For this to work, change the symlink script to create the symlink's containing directory if it doesn't yet exist. I locally verified that CMake and GN build create the same bundle structure. (I noticed that both builds set LC_ID_DYLIB to the pre-copy libClangdXPCLib.dylib name, but that seems to not cause any issues and it happens in the CMake build too.) (Also add an error message to clangd-xpc-test-client for when loading the dylib fails – this was useful while locally debugging this.) Differential Revision: https://reviews.llvm.org/D60130 llvm-svn: 357574
* Fix file headers. NFCFangrui Song2019-03-012-2/+2
| | | | llvm-svn: 355188
* Added missing license headersDmitri Gribenko2019-02-282-0/+15
| | | | | | | | | | | | Reviewers: ioeric Subscribers: jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58781 llvm-svn: 355092
* [clangd] Library dependencies in XPCJan Korous2019-02-271-2/+2
| | | | | | | | Patch by Nicholas Allegra Differential Revision: https://reviews.llvm.org/D58089 llvm-svn: 354949
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [clangd] XPC transport layerJan Korous2019-01-1612-0/+584
- New transport layer for macOS. - XPC Framework - Test client Framework and client were written by Alex Lorenz. Differential Revision: https://reviews.llvm.org/D54428 llvm-svn: 351280
OpenPOWER on IntegriCloud