Since its beginning the Ninja generator has handled `GENERATED` source
files that have no custom command producing them by writing a dummy
custom command for them that depends on the target ordering phony edge.
Make the custom command's dependency order-only since the phony edge
also has only order-only dependencies. The dummy custom command
should never be considered "dirty" by `ninja`.
Fixes: #17942
Since commit v3.9.0-rc1~230^2~2 (ninja: break unnecessary target
dependencies, 2017-04-17) we unconditionally generate a phony edge for
target ordering. It is needed in case a later target depends on it.
However, if the phony edge has no inputs then `ninja -d explain` prints:
ninja explain: output ... of phony edge with no inputs doesn't exist
Furthermore the phony edge's output is considered dirty and can cause
dependents to be incorrectly considered dirty. Avoid this by always
generating at least one input to the target ordering phony edges.
If we have no real dependencies just use a path that always exists.
Fixes: #17942
Internally we mark `file(GENERATE)` outputs as `GENERATED` in order
to tell custom command dependency tracing logic not to expect the
files to exist on disk yet. This is because we do not generate the
files until after that tracing is done.
The Ninja generator also interprets the `GENERATED` property to mean
that it is expected that some build rule will generate the file if
another build rule depends on it. If the generator does not know of a
custom command that generates the file then it adds an empty one so that
the `ninja` build tool does not complain about a dependency on a file
that does not exist and has no rule to generate it. However, this step
is not necessary for `file(GENERATE)` outputs because there is no build
rule to generate them and they will exist before `ninja` runs.
Add an additional `__CMAKE_GENERATED_BY_CMAKE` property internally to
tell the Ninja generator that a `GENERATED` file will exist before the
build starts and is not expected to have a build rule producing it.
Fixes: #17942
f59c33a763 VS: Generate a custom command only in the least dependent target
d58d4daa6b cmVisualStudio10TargetGenerator: Use cmLocalVisualStudio10Generator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1889
The change in commit v3.11.0-rc1~480^2 (UseJava: add_jar OUTPUT_DIR
option used only for jar generation, 2017-10-12) added code of the form
`file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR})`. This exposed an existing
bug in `CMAKE_DISABLE_SOURCE_CHANGES` in which it does not recognize
that the top of the build tree itself is in the build tree. Fix that
now.
Fixes: #17933
An effect of the `-isystem` flag is to search the directory after those
specified via `-I` flags. Make behavior more consistent on compilers
that do not have any `-isystem` flag by explicitly moving system include
directories to the end.
When cross-compiling on a Windows host, we use a `:cmake_mode_t` NTFS
alternate stream to store the file mode for use during packaging.
Writing to this stream changes the file modification time, so save and
restore the original modification time since we are not modifying the
real file content.
Fixes: #17922
b1f95e5b14 Fortran: Extend submodule test with great-grandchild
402735314e Fortran: Add support for submodule dependencies
62538b2c4c Fortran: Refactor to treat .mod extension as part of module name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Izaak Beekman <contact@izaakbeekman.com>
Merge-request: !1989
If a custom command is assigned to multiple targets, generate the build
rule only in the least-dependent `.vcxproj` file. Otherwise MSBuild
will run the command on the first build of a dependent target even if
its dependencies already brought the command up to date (in order to
populates its build log).
Generate targets in least-to-most-dependent order, and assign a custom
command to the least dependent target.
Added cmLocalVisualStudio10Generator::GenerateTargetsDepthFirst to call
cmVisualStudio10TargetGenerator::Generate in least-dependent order.
Moved SourcesVisited from cmVisualStudio10TargetGenerator to
cmLocalVisualStudio10Generator to avoid attaching a custom command to
multiple targets among the local generator.
Fixes: #16767
Since commit v3.7.0-rc1~73^2~1 (Fortran: Add support for submodule
syntax in dependency scanning, 2016-09-05) we support parsing Fortran
sources that use submodule syntax, but it left addition of `.smod`
dependencies to future work. Add it now.
The syntax
submodule (module_name) submodule_name
means the current source requires `module_name.mod` and provides
`module_name@submodule_name.smod`. The syntax
submodule (module_name:submodule_name) nested_submodule_name
means the current source requires `module_name@submodule_name.smod`
provides `module_name@nested_submodule_name.smod`.
Fixes: #17017
When tracking module names internally, include the `.mod` extension.
This will later be useful to distinguish them from `.smod` extensions
for submodules.
Create `CMAKE_VS_SDK_*_DIRECTORIES` variables to tell the VS generator
how to populate fields in `.vcxproj` files that specify SDK directories.
Fixes: #17908
Other check modules honor this variable, so include file checks should
too. Add policy `CMP0075` to enable the behavior in a compatible way.
This change was originally made by commit v3.11.0-rc1~108^2
(CheckIncludeFiles: Honor CMAKE_REQUIRED_LIBRARIES, 2017-12-24) but it
was reverted by commit v3.11.1~9^2 (Revert "CheckIncludeFiles: Honor
CMAKE_REQUIRED_LIBRARIES", 2018-04-04) because the behavior change could
affect checks in existing projects in an incompatible way.
Fixes: #9514
Policies affecting the behavior of CMake-provided macros and functions
need to be able to get the policy setting as of the call site rather
than the definition site. Add an undocumented option to do this.
The OpenWatcom tools do not fail to link when a library is missing if no
symbols were needed from it. This can break `try_compile` checks.
Teach `cmGlobalGenerator::Build` to pretend that the build tool returned
non-zero if the output contains the corresponding warning.
