maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/tools/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

43 lines
1.4 KiB
CMake
Raw Normal View History

[CMake] Make clang/tools subdirectories controlled via options Setting CLANG_TOOL_*_BUILD=Off on the CMake command line will disable inclusion of a clang/tools subdirectory. llvm-svn: 250840
2015-10-21 02:12:12 +08:00
create_subdirectory_options(CLANG TOOL)
Fix dependencies now that the ARC migrator depends on the static analyzer. Thanks for pointing this out, Stephen. I think this is right now -- I attempted to try all four valid combinations with both the autoconf and CMake builds. See also LLVM changes to the configure script. llvm-svn: 189027
2013-08-22 23:50:02 +08:00
[CMake] Make clang/tools subdirectories controlled via options Setting CLANG_TOOL_*_BUILD=Off on the CMake command line will disable inclusion of a clang/tools subdirectory. llvm-svn: 250840
2015-10-21 02:12:12 +08:00
add_clang_subdirectory(diagtool)
add_clang_subdirectory(driver)
[clang-diff] Add initial implementation This is the first commit for the "Clang-based C/C++ diff tool" GSoC project. ASTDiff is a new library that computes a structural AST diff between two ASTs using the gumtree algorithm. Clang-diff is a new Clang tool that will show the structural code changes between different ASTs. Patch by Johannes Altmanninger! Differential Revision: https://reviews.llvm.org/D34329 llvm-svn: 308731
2017-07-21 20:49:28 +08:00
add_clang_subdirectory(clang-diff)
[CMake] Make clang/tools subdirectories controlled via options Setting CLANG_TOOL_*_BUILD=Off on the CMake command line will disable inclusion of a clang/tools subdirectory. llvm-svn: 250840
2015-10-21 02:12:12 +08:00
add_clang_subdirectory(clang-format)
add_clang_subdirectory(clang-format-vs)
add_clang_subdirectory(clang-fuzzer)
Testbed and skeleton of a new expression parser Recommitted after formal approval. LLVM's JIT is now the foundation of dynamic-compilation features for many languages. Clang also has low-level support for dynamic compilation (ASTImporter and ExternalASTSource, notably). How the compiler is set up for dynamic parsing is generally left up to individual clients, for example LLDB's C/C++/Objective-C expression parser and the ROOT project. Although this arrangement offers external clients the flexibility to implement dynamic features as they see fit, the lack of an in-tree client means that subtle bugs can be introduced that cause regressions in the external clients but aren't caught by tests (or users) until much later. LLDB for example regularly encounters complicated ODR violation scenarios where it is not immediately clear who is at fault. Other external clients (notably, Cling) rely on similar functionality, and another goal is to break this functionality up into composable parts so that any client can be built easily on top of Clang without requiring extensive additional code. I propose that the parts required to build a simple expression parser be added to Clang. Initially, I aim to have the following features: A piece that looks up external declarations from a variety of sources (e.g., from previous dynamic compilations, from modules, or from DWARF) and uses clear conflict resolution rules to reconcile differences, with easily understood errors. This functionality will be supported by in-tree tests. A piece that works hand in hand with the LLVM JIT to resolve the locations of external declarations so that e.g. variables can be redeclared and (for high-performance applications like DTrace) external variables can be accessed directly from the registers where they reside. This commit adds a tester that parses a sequence of source files and then uses them as source data for an expression. External references are resolved using an ExternalASTSource that responds to name queries using an ASTImporter. This is the setup that LLDB uses, and the motivating reason for MinimalImport in ASTImporter. When complete, this tester will implement the first of the above goals. Differential Revision: https://reviews.llvm.org/D27180 llvm-svn: 290367
2016-12-23 04:03:14 +08:00
add_clang_subdirectory(clang-import-test)
clang-offload-bundler - offload files bundling/unbundling tool Summary: One of the goals of programming models that support offloading (e.g. OpenMP) is to enable users to offload with little effort, by annotating the code with a few pragmas. I'd also like to save users the trouble of changing their existent applications' build system. So having the compiler always return a single file instead of one for the host and each target even if the user is doing separate compilation is desirable. This diff proposes a tool named clang-offload-bundler (happy to change the name if required) that is used to bundle files associated with the same user source file but different targets, or to unbundle a file into separate files associated with different targets. This tool supports the driver support for OpenMP under review in http://reviews.llvm.org/D9888. The tool is used there to enable separate compilation, so that the very first action on input files that are not source files is a "unbundling action" and the very last non-linking action is a "bundling action". The format of the bundled files is currently very simple: text formats are concatenated with comments that have a magic string and target identifying triple in between, and binary formats have a header that contains the triple and the offset and size of the code for host and each target. The goal is to improve this tool in the future to deal with archive files so that each individual file in the archive is properly dealt with. We see that archives are very commonly used in current applications to combine separate compilation results. So I'm convinced users would enjoy this feature. This tool can be used like this: `clang-offload-bundler -targets=triple1,triple2 -type=ii -inputs=a.triple1.ii,a.triple2.ii -outputs=a.ii` or `clang-offload-bundler -targets=triple1,triple2 -type=ii -outputs=a.triple1.ii,a.triple2.ii -inputs=a.ii -unbundle` I implemented the tool under clang/tools. Please let me know if something like this should live somewhere else. This patch is prerequisite for http://reviews.llvm.org/D9888. Reviewers: hfinkel, rsmith, echristo, chandlerc, tra, jlebar, ABataev, Hahnfeld Subscribers: whchung, caomhin, andreybokhanko, arpith-jacob, carlo.bertolli, mehdi_amini, guansong, Hahnfeld, cfe-commits Differential Revision: https://reviews.llvm.org/D13909 llvm-svn: 279632
2016-08-24 23:21:05 +08:00
add_clang_subdirectory(clang-offload-bundler)
[Clang][OpenMP Offload] Add new tool for wrapping offload device binaries This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver. This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943). Differential Revision: https://reviews.llvm.org/D68166 llvm-svn: 374219
2019-10-10 04:42:58 +08:00
add_clang_subdirectory(clang-offload-wrapper)
[clang-scan-deps] initial outline of the tool that runs preprocessor to find dependencies over a JSON compilation database This commit introduces an outline for the clang-scan-deps tool that will be used to implement fast dependency discovery phase using implicit modules for explicit module builds. The initial version of the tool works by computing non-modular header dependencies for files in the compilation database without any optimizations (i.e. without source minimization from r362459). The tool spawns a number of worker threads to run the clang compiler workers in parallel. The immediate goal for clang-scan-deps is to create a ClangScanDeps library which will be used to build up this tool to use the source minimization and caching multi-threaded filesystem to implement the optimized non-incremental dependency scanning phase for a non-modular build. This will allow us to do benchmarks and comparisons for performance that the minimization and caching give us Differential Revision: https://reviews.llvm.org/D60233 llvm-svn: 363204
2019-06-13 05:32:49 +08:00
add_clang_subdirectory(clang-scan-deps)
[CMake] Make clang/tools subdirectories controlled via options Setting CLANG_TOOL_*_BUILD=Off on the CMake command line will disable inclusion of a clang/tools subdirectory. llvm-svn: 250840
2015-10-21 02:12:12 +08:00
add_clang_subdirectory(c-index-test)
Fix the !CLANG_ENABLE_ARCMT build llvm-svn: 212995
2014-07-15 06:17:16 +08:00
[refactor] Move clang-rename into the clang repository The core engine of clang-rename will be used for local and global renames in the new refactoring engine, as mentioned in http://lists.llvm.org/pipermail/cfe-dev/2017-June/054286.html. The clang-rename tool is still supported but might get deprecated in the future. Differential Revision: https://reviews.llvm.org/D34696 llvm-svn: 306840
2017-07-01 00:36:09 +08:00
add_clang_subdirectory(clang-rename)
[refactor] add clang-refactor tool with initial testing support and local-rename action This commit introduces the clang-refactor tool alongside the local-rename action which uses the existing renaming engine used by clang-rename. The tool doesn't actually perform the source transformations yet, it just provides testing support. This commit also moves only one test from clang-rename over to test/Refactor. I will continue to move the other tests throughout development of clang-refactor. The following options are supported by clang-refactor: -v: use verbose output -selection: The source range that corresponds to the portion of the source that's selected (currently only special command test:<file> is supported). Please note that a follow-up commit will migrate clang-refactor to libTooling's common option parser, so clang-refactor will be able to use the common interface with compilation database and options like -p, -extra-arg, etc. The testing support provided by clang-refactor is described below: When -selection=test:<file> is given, clang-refactor will parse the selection commands from that file. The selection commands are grouped and the specified refactoring action invoked by the tool. Each command in a group is expected to produce an identical result. The precise syntax for the selection commands is described in a comment in TestSupport.h. Differential Revision: https://reviews.llvm.org/D36574 llvm-svn: 313244
2017-09-14 18:06:52 +08:00
add_clang_subdirectory(clang-refactor)
Re-land: Add Clang shared library with C++ exports Summary: This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two. This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries. llvm-svn: 360985
2019-05-17 12:20:01 +08:00
if(UNIX)
add_clang_subdirectory(clang-shlib)
endif()
[refactor] Move clang-rename into the clang repository The core engine of clang-rename will be used for local and global renames in the new refactoring engine, as mentioned in http://lists.llvm.org/pipermail/cfe-dev/2017-June/054286.html. The clang-rename tool is still supported but might get deprecated in the future. Differential Revision: https://reviews.llvm.org/D34696 llvm-svn: 306840
2017-07-01 00:36:09 +08:00
Fix dependencies now that the ARC migrator depends on the static analyzer. Thanks for pointing this out, Stephen. I think this is right now -- I attempted to try all four valid combinations with both the autoconf and CMake builds. See also LLVM changes to the configure script. llvm-svn: 189027
2013-08-22 23:50:02 +08:00
if(CLANG_ENABLE_ARCMT)
[CMake] Make clang/tools subdirectories controlled via options Setting CLANG_TOOL_*_BUILD=Off on the CMake command line will disable inclusion of a clang/tools subdirectory. llvm-svn: 250840
2015-10-21 02:12:12 +08:00
add_clang_subdirectory(arcmt-test)
add_clang_subdirectory(c-arcmt-test)
Fix dependencies now that the ARC migrator depends on the static analyzer. Thanks for pointing this out, Stephen. I think this is right now -- I attempted to try all four valid combinations with both the autoconf and CMake builds. See also LLVM changes to the configure script. llvm-svn: 189027
2013-08-22 23:50:02 +08:00
endif()
Make clang's rewrite engine a core feature The rewrite facility's footprint is small so it's not worth going to these lengths to support disabling at configure time, particularly since key compiler features now depend on it. Meanwhile the Objective-C rewriters have been moved under the ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still potentially worth excluding from lightweight builds. Tests are now passing with any combination of feature flags. The flags historically haven't been tested by LLVM's build servers so caveat emptor. llvm-svn: 213171
2014-07-17 00:48:33 +08:00
With CLANG_ENABLE_STATIC_ANALYZER=0, link clang properly and skip clang-check. Previously, the CMake build still tried to link clang against the static analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off. Furthermore, clang-check depends on the analyzer, so it should be disabled (in both CMake and configure builds). In theory, clang-check could be made to conditionally include analyzer support (like clang itself), but for now this at least gets a CMake ALL_BUILD working. Patch by Stephen Kelly, modified by me. llvm-svn: 185548
2013-07-04 00:20:29 +08:00
if(CLANG_ENABLE_STATIC_ANALYZER)
[CMake] Make clang/tools subdirectories controlled via options Setting CLANG_TOOL_*_BUILD=Off on the CMake command line will disable inclusion of a clang/tools subdirectory. llvm-svn: 250840
2015-10-21 02:12:12 +08:00
add_clang_subdirectory(clang-check)
[analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions Summary: This is just changing naming and documentation to be general about external definitions that can be imported for cross translation unit analysis. There is at least a plan to add VarDecls: D46421 Reviewers: NoQ, xazax.hun, martong, a.sidorin, george.karpenkov, serge-sans-paille Reviewed By: xazax.hun, martong Subscribers: mgorny, whisperity, baloghadamsoftware, szepet, rnkovacs, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D56441 llvm-svn: 350852
2019-01-11 01:44:04 +08:00
add_clang_subdirectory(clang-extdef-mapping)
Install scan-build and scan-view only if Static Analyzer was enabled. llvm-svn: 257562
2016-01-13 10:03:50 +08:00
add_clang_subdirectory(scan-build)
add_clang_subdirectory(scan-view)
With CLANG_ENABLE_STATIC_ANALYZER=0, link clang properly and skip clang-check. Previously, the CMake build still tried to link clang against the static analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off. Furthermore, clang-check depends on the analyzer, so it should be disabled (in both CMake and configure builds). In theory, clang-check could be made to conditionally include analyzer support (like clang itself), but for now this at least gets a CMake ALL_BUILD working. Patch by Stephen Kelly, modified by me. llvm-svn: 185548
2013-07-04 00:20:29 +08:00
endif()
Initial support for recursing into the new clang-tools-extra repository if checked out under clang/tools/extra. This is mostly so folks other than me can start to test. Documentation, details, and an announcement are still in the works. llvm-svn: 161405
2012-08-07 16:37:42 +08:00
# We support checking out the clang-tools-extra repository into the 'extra'
# subdirectory. It contains tools developed as part of the Clang/LLVM project
# on top of the Clang tooling platform. We keep them in a separate repository
# to keep the primary Clang repository small and focused.
[CMake] clang/tools/extra may be included by LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR. LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR=/path/to/llvm-srcroot/tools/clang/tools/extra, by default. llvm-svn: 165620
2012-10-10 21:46:18 +08:00
# It also may be included by LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR.
add_llvm_external_project(clang-tools-extra extra)
Tweak CMakeLists not for libclang to depend on the variable CLANG_TOOL_EXTRA_BUILD. llvm-svn: 262606
2016-03-03 19:09:43 +08:00
# libclang may require clang-tidy in clang-tools-extra.
add_clang_subdirectory(libclang)