summaryrefslogtreecommitdiffstats
path: root/Source/cmFileAPI.h
Commit message (Collapse)AuthorAgeFilesLines
* cmFileAPI: Add "toolchains" object kind.Ben McMorran2021-01-121-0/+5
| | | | Fixes #19514
* Modernize: Use #pragma once in all header filesKitware Robot2020-09-031-4/+1
| | | | | | | | | | | | | | | | #pragma once is a widely supported compiler pragma, even though it is not part of the C++ standard. Many of the issues keeping #pragma once from being standardized (distributed filesystems, build farms, hard links, etc.) do not apply to CMake - it is easy to build CMake on a single machine. CMake also does not install any header files which can be consumed by other projects (though cmCPluginAPI.h has been deliberately omitted from this conversion in case anyone is still using it.) Finally, #pragma once has been required to build CMake since at least August 2017 (7f29bbe6 enabled server mode unconditionally, which had been using #pragma once since September 2016 (b13d3e0d)). The fact that we now require C++11 filters out old compilers, and it is unlikely that there is a compiler which supports C++11 but does not support #pragma once.
* Refactoring: Third-parties public headers are under cm3p prefixMarc Chevrier2020-05-071-3/+3
| | | | Fixes: #20666
* Revise include order using clang-format-6.0Kitware Robot2019-10-011-4/+4
| | | | | Run the `clang-format.bash` script to update our C and C++ code to a new include order `.clang-format`. Use `clang-format` version 6.0.
* IWYU: Fix handling of <memory> standard headerBrad King2019-07-101-1/+1
| | | | | | | | An old workaround for `std::allocator_traits<>::value_type` lints from IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`. Convert the workaround to use the same approach we already use for a workaround of `std::__decay_and_strip<>::::__type` lints. Then update the `<memory>` inclusions to follow the now-correct IWYU lints.
* cmake: Teach -E capabilities to report supported fileapi requestsBrad King2019-06-071-0/+3
| | | | Fixes: #19339
* fileapi: Factor out helper to construct a version objectBrad King2019-06-071-0/+2
|
* fileapi: add cmakeFiles v1Brad King2018-12-121-0/+5
| | | | Issue: #18398
* fileapi: add cache v2Brad King2018-12-121-0/+5
| | | | | | Start with v2 to distinguish it from server-mode v1. Issue: #18398
* fileapi: add codemodel v2Brad King2018-12-121-0/+5
| | | | | | Start with v2 to distinguish it from server-mode v1. Issue: #18398
* fileapi: Add helper to create and reference a json reply fileBrad King2018-12-121-0/+5
|
* fileapi: Add protocol v1 support for stateful per-client queriesBrad King2018-12-121-1/+72
| | | | | | | | | | | | Add support for client-owned *stateful* query files. These allow clients to request a list of versions of each object kind and get only the first-listed version that CMake recognizes. Since clients own their stateful query files they can mutate them over time. As a client installation is updated it may update the queries that it writes to build trees to get newer object versions without paying the cost of continuing to generate older versions. Issue: #18398
* fileapi: Add protocol v1 support for client-specific query filesBrad King2018-12-121-0/+4
| | | | | | | | Add support for client-owned stateless query files. These allow clients to *own* requests for major object versions and get all those recognized by CMake. Issue: #18398
* fileapi: Add protocol v1 infrastructure with support for shared query filesBrad King2018-12-121-0/+109
Add a file-based API that clients may use to get semantic information about the buildsystem that CMake generates. Clients will write query files under a designated location in the build tree, and CMake will write reply files for clients to read. Start with support for shared stateless query files. These allow clients to share requests for major object versions and get all those recognized by CMake. Once any client has written a shared request to a build tree it will persist. Other clients will not need to overwrite the request (since it is stateless) and should not remove it either. For now we add only an undocumented object kind to use for testing the query and reply infrastructure. Object kinds providing real semantic information will be added later. Issue: #18398