These source file types don't necessarily show up in the CMake code, but
are side effects of other behaviors in CMake. Support tracking them
specially so that heuristics are not required to figure out if a given
`cmSourceFile` is one of them.
Not just short directory roots. The test suites did an improper
generator check and masked them as the generator masks were put in place
after the core development but before the autogen-specific logic tests
were created.
Note that this does lose the backtrace information. It also, however,
makes `PRECOMPILE_HEADERS_REUSE_FROM` a non-magic property now.
Previously, appending to the property would miss all of its behaviors
(or leave existing setup in-place which is no longer relevant
post-append). Rather than making a policy to block appending, just defer
all logic to generation time.
Now that generation can work with any way the state gets to the way it
is, just do the target enforcement at generation time. This allows PCH
reuse targets to be declared before or after targets which use them.
Also update `cmLocalGenerator` to use the methods now that they reliably
provide values rather than parallel construction.
The property settings set things up once, but nothing ensures that
post-reuse hookup that any property changes propagate. Instead, when
computing PDB information, if PCH reuse is enabled, just always use its
values.
Also drop enforcement at generate time of property value consistency as
it is now ignored when PCH reuse is in effect.
Additionally, if a target is PCH-reused, generate a PDB output directory
for it.
The `PchReuseFromIgnoreOwnProps` test failed previously because the
post-reuse link update of the consuming `PDB` properties are no longer
considered. The `PchReuseFromUseUpdatedProps` failed because the
post-reuse link did not update the copy of the properties added to
consuming reuse target properties.
c95a8348ce cmLocalGenerator: add an override for CMakeFiles-using paths
35d32b8741 cmLocalGenerator: move the `CMakeFiles` subdir from the target to output root
bc19e42461 generators: use `GetObjectOutputRoot` to compute target directories
b1d9a5313c cmLocalGenerator: add a `GetObjectOutputRoot` method
b82a74d918 generators: use GetSupportDirectory() in more places
36f85ee0cc cmGeneratorTarget: query the local generator for the target directory
ff5d7bc301 cmLocalXCodeGenerator: use a per-target directory
aafd771529 cmNinjaTargetGenerator: use `GetObjectFileDir` where possible
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10812
Visual Studio doesn't use a `CMakeFiles` subdirectory for its support
directories. However, some codepaths expect to use paths which are
always under `CMakeFiles`. Add a mechanism to keep the path for such
files.
The nested Swift module structure is recommended for Swift projects.
This structure has an outer directory called
`<Swift_MODULE_NAME>.swiftmodule` that contains generated files for the
interface. The binary swift modules, textual swift interface, and other
supplemental outputs that make up the interface to a Swift library all
go in this outer directory with the Swift module triple as the filename
followed by the appropriate file extension based on what that file
contains.
Issue: #19284
CMake now provides the CMAKE_<LANG>_LINK_MODE variable which specify how
the link step is done. So, the CMAKE_<LANG>_USING_LINKER_MODE variable
is no longer needed.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Issue: #26123
785523a136 Remove compatibility with CMake versions older than 2.8.0
35282387ea CMP0014: Remove support for OLD behavior
fad9c55b8b CMP0013: Remove support for OLD behavior
98a59ba8ad CMP0012: Remove support for OLD behavior
3c0dbb66f5 CMP0011: Remove support for OLD behavior
cf832e75bc CMP0010: Remove support for OLD behavior
77f8c374f3 CMP0009: Remove support for OLD behavior
43ef139567 CMP0008: Remove support for OLD behavior
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !10188
9d34069ca8 instrumentation: Add targetLabels field to link snippets
32444714e5 instrumentation: Update tests so that snippet verification runs
11bcf2efb8 instrumentation: Correct example v1 Data snippet in manual
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Acked-by: Roscoe A. Bartlett <rabartl@sandia.gov>
Merge-request: !10185
In commit fe3f846e1b (Makefiles: Add support for building Fortran
intrinsics, 2020-11-19, v3.22.0-rc1~565^2) the property was added with
incorrect spelling `Fortran_BUILDING_INSTRINSIC_MODULES`. Add a new
property with the correct spelling. Keep the old one for compatibility.
Issue: #21463
