Projects can use the new command to request file API replies for the current
run. No query files are generated, the query is tracked internally. Replies are
created in the file system at generation time in the usual way.
Fixes: #24951
Prior to jsoncpp commit `126bdc2b05` (Reject extra chars if strictRoot,
2016-08-21, 1.7.5~2), it did not diagnose trailing characters in the
input after a JSON value. Teach our corresponding test case to tolerate
the old behavior.
* Adding tests for CMP0118 being unset (aka set to `WARN`).
* Adjusting the (unrelated) RunCMake.CMP0026 test to set CMP0118 to
`NEW`,
* Adjusting the (unrelated) RunCMake.Ninja test to set CMP0118 to `OLD`.
* Adjusting the (unrelated) RunCMake.FileAPI test to set CMP0118 to
`OLD`.
Note:
Setting CMP0118 to `NEW` and modifying the `GENERATED` property with
`set_property` or `set_source_files_properties` will currently NOT set
that property because the implementation is still to come.
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
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
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
