summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/FileAPI
Commit message (Collapse)AuthorAgeFilesLines
* fileapi: add some source property backtracesJustin Goshi2019-09-261-4/+61
| | | | | Support backtraces for COMPILE_DEFINITIONS, COMPILE_OPTIONS, and INCLUDE_DIRECTORIES source properties.
* fileapi: add backtraces for LINK_PATH and LINK_DIRECTORIESJustin Goshi2019-09-182-2/+39
|
* fileapi: add backtraces for compile/link optionsJustin Goshi2019-09-102-4/+129
|
* Merge topic 'fileapi-install-generators'Brad King2019-08-052-1/+36
|\ | | | | | | | | | | | | d70a0f8681 fileapi: Fix codemodel target install destination for cross-dir rules Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3639
| * fileapi: Fix codemodel target install destination for cross-dir rulesBrad King2019-07-312-1/+36
| | | | | | | | | | | | | | | | | | | | | | | | Since commit e89ad0f94e (install: Allow installing targets created in another directory, 2018-06-18, v3.13.0-rc1~407^2) we support calling `install(TARGETS)` for targets created in another directory. However, install generators are associated with the directory in which the call to `install()` appears. This may not be the same directory in which the target is defined. Record in each target the list of install generators it has. Fixes: #19546
* | AIX: Create import library for executables with exportsBrad King2019-07-161-0/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On AIX, plugins meant to be loaded into executables via `dlopen` must be linked with access to a list of symbols exported from the executable in order to use them (when not using runtime linking). The AIX linker supports specifying this list as an "import file" passed on the command line either via the `-bI:...` option or (with a leading `#! .` line) as a normal input file like any other library file. The linker import file plays the same role on AIX as import libraries do on Windows. Teach CMake to enable its import library abstraction on AIX for executables with the `ENABLE_EXPORTS` target property set. Teach our internal `ExportImportList` script to optionally generate a leading `#! .` line at the top of the generated export/import list. Update our rule for linking an executable with exports to generate a public-facing "import library" implemented as an AIX linker import file. With this approach, our existing infrastructure for handling import libraries on Windows will now work for AIX linker import files too: * Plugins that link to their executable's symbols will be automatically linked using the import file on the command line. * The executable's import file will be (optionally) installed and exported for use in linking externally-built plugins. This will allow executables and their plugins to build even if we later turn off runtime linking. Issue: #19163
* fileapi: extend codemodel v2 with directory detailsBrad King2018-12-121-0/+26
| | | | | Issue: #18398 Co-Author: Kyle Edwards <kyle.edwards@kitware.com>
* fileapi: extend codemodel v2 with a project modelBrad King2018-12-122-3/+259
| | | | | | | | | Offer clients a `project()`-centric view of the build system. This is similar to the directory-centric view but consolidates subdirectories that do not call `project()` with a new project name. Issue: #18398 Co-Author: Kyle Edwards <kyle.edwards@kitware.com>
* fileapi: Add test for cmakeFiles v1Kyle Edwards2018-12-125-1/+89
|
* fileapi: add cmakeFiles v1Brad King2018-12-129-0/+56
| | | | Issue: #18398
* fileapi: Add test for cache v2Kyle Edwards2018-12-122-2/+134
|
* fileapi: add cache v2Brad King2018-12-129-0/+57
| | | | | | Start with v2 to distinguish it from server-mode v1. Issue: #18398
* fileapi: Add test for codemodel v2Kyle Edwards2018-12-1213-14/+4915
|
* fileapi: add codemodel v2Brad King2018-12-129-0/+67
| | | | | | Start with v2 to distinguish it from server-mode v1. Issue: #18398
* fileapi: Add more infrastructure to FileAPI testKyle Edwards2018-12-121-7/+65
|
* fileapi: Report cmake generator in reply index fileBrad King2018-12-121-1/+12
|
* fileapi: Add protocol v1 support for stateful per-client queriesBrad King2018-12-126-0/+406
| | | | | | | | | | | | 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-1217-0/+191
| | | | | | | | 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-1217-0/+205
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
generated by cgit v0.12 at 2025-01-21 00:04:25 (GMT)