summaryrefslogtreecommitdiff
path: root/Source/cmScanDepFormat.cxx
Commit message (Collapse)AuthorAgeFilesLines
* cmScanDepFormat: Accept P1689r4 files with version 1Brad King2021-11-031-1/+1
| | | | | VS 2022's `cl` 19.30 has a `-scanDependencies` option that produces the P1689r4 format. It reports the "version" field with value "1".
* cmScanDepFormat: Remove Fortran-specific compiled-module-path logicBrad King2021-06-151-9/+2
| | | | | | | Read and write the `compiled-module-path` field only when explicitly known. Move the assumption that the `compiled-module-path` can be derived from the logical module name from the scandep parser to the `cmake_ninja_dyndep` helper.
* cmScanDepFormat: Avoid writing lookup-method with default valueBrad King2021-06-151-4/+4
|
* cmScanDepFormat: P1689R4: Implement source-path related fieldsBen Boeckel2021-06-101-3/+104
|
* cmScanDepFormat: P1689R4: Make work-directory optionalBen Boeckel2021-06-091-4/+10
|
* cmScanDepFormat: P1689R4: Factor out primary-output fieldBen Boeckel2021-06-091-9/+16
|
* cmScanDepFormat: P1689R4: Diagnose invalid provides/requires json typeBen Boeckel2021-06-091-30/+40
|
* cmScanDepFormat: P1689R4: Flatten future-compile members into parentBen Boeckel2021-06-091-54/+48
|
* cmScanDepFormat: Drop unused "outputs", "inputs", and "depends" fieldsBrad King2021-05-131-22/+3
| | | | | | | These fields are specified by our `P1689r3` paper, but are not actually needed. The dependencies of the scanning results themselves can be captured via normal depfile logic. Avoid saving this possibly-large information in the scanning results. It is not needed by later steps.
* Ninja: Restore support for Fortran in a symlinked build treeBrad King2021-05-121-6/+5
| | | | | | | | | | | | | | | | | | | Since commit f3eed2c49d (cmGlobalNinjaGenerator: use P1689 dependency file format for Fortran, 2019-03-12, v3.20.0-rc1~454^2), Fortran stopped working in a build tree whose path contains a symlink. The reason is that the P1689r3 format's `work-directory` field gets populated with the realpath (via `getcwd`) of the build tree instead of the logical path to the build tree used for generating relative paths in `build.ninja`. This causes the `Fortran.dd` file to get absolute (real)paths to `.o` files, and Ninja does not match them with the relative `.o` file paths in `build.ninja`. Fix this by dropping use of the `work-directory` field. This restores our prior approach of generating paths in the dyndep file using the same forms of paths received from the buildsystem generator. The P1689r3 paper's format may need to be revised to account for this. Fixes: #21683
* cmScanDepFormat: Fix name of our internal tool in parse errorsBrad King2021-01-051-13/+11
| | | | | We parse the scan result `.ddi` files in `-E cmake_ninja_dyndep`, not `-E cmake_ninja_depends`.
* scandep: update format to P1689 R3Brad King2020-11-181-52/+30
| | | | | | | | | The `work-directory` field has been moved into individual rules since each one may correspond to a different compiler invocation and therefore a different work directory. Support for arbitrary binary paths has been removed for simplicity. We now assume paths have a valid UTF-8 round-trip representation.
* cmScanDepFormat: add reader and writer for the format from P1689R2Ben Boeckel2020-11-171-0/+289
This format is currently subject to change, but is not too far from the end goal. Some bits are currently unimplemented (see TODO comments).
View Lorry Controller Status