7ab9a625 Makefiles: Drop 'requires' step and its supporting infrastructure
5f2e2c38 Makefiles: Avoid nested make calls for Fortran module dependencies
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1523
The 'requires' step was used to provide implicit dependencies between
the generated Fortran module files and a Fortran target that needs these
module files to ensure the correct compilation order. After recent
refactoring to resolve all dependencies explicitly through `.mod.stamp`
make targets, the separate 'requires' step is not needed anymore.
Makefiles generated by cmake use a series of nested calls to build
`*.provides.build` targets that are used when the 'requires' step is
needed. That leads to significant degradation of the build time for
incremental builds. Re-arrange dependencies to eliminate the nested
calls.
Explicit `.mod.stamp` targets introduced by this commit could lead to
situation when a stamp file always older than its dependency. This
happens during the incremental build when building of an updated Fortran
source produces a module file that has no differences from the stored
stamp file. In such case `cmake_copy_f90_mod` will be triggered on each
new build to compare a module file with the corresponding stamp file.
This behavior is expected and can not be changed without nested calls
that slow down the build. The copy-if-different check is much cheaper
than an entire nested make call.
Refactoring in commit 66419bc046 (CTest: convert timeouts to
std::chrono::duration, 2017-11-20) changed out "infinite" timeout to a
value not representable by a 64-bit integer. This causes undefined
behavior when e.g. KWSys Process converts the duration to a `long` to
interact with system APIs. Use the old `1.0e7` maximum value.
The ratio of ticks to seconds for this type is 1, so we can just use its
`count()` directly. This also avoids converting through the integer
representation of `std::chrono::milliseconds`, which has a much smaller
allowed range.
Drop our `cmsysProcess_SetTimeout` wrapper as it is now very thin.
Refactoring in commit 66419bc046 (CTest: convert timeouts to
std::chrono::duration, 2017-11-20) changed out "infinite" timeout
to a value not representable by a 64-bit integer. Update the
`--build-and-test` forwarding of `--test-timeout` to not forward
an "infinite" timeout.
Refactoring in commit 66419bc046 (CTest: convert timeouts to
std::chrono::duration, 2017-11-20) accidentally changed the logic used
to compute the timeout for a test when it starts. It incorrectly limits
the maximum possible timeout to 2 minutes rather than 2 minutes less
than the total allowed test time remaining. Update the new logic to
restore the original behavior.
Avoid subtracting 2 minutes from our "infinite" timeout value to avoid
creating very large timeouts that are not "infinite" and may exceed
integer type ranges.
Library dependencies of the origin target were forwarded to the
_autogen target as source file dependencies. This is fixed by
forwarding the dependencies as target dependencies instead.
Issue: #17278
Revert the library target dependency forwarding to the `_autogen` target
to the 3.9.6 way, only now using `GetLinkImplementationLibraries`.
Fixes: #17278
Refactoring in commit 66419bc046 (CTest: convert timeouts to
std::chrono::duration, 2017-11-20) accidentally changed the logic used
to compute the timeout for a test when it starts. It incorrectly limits
the maximum possible timeout to 2 minutes rather than 2 minutes less
than the total allowed test time remaining. Update the new logic to
restore the original behavior.
Avoid subtracting 2 minutes from our "infinite" timeout value to avoid
creating very large timeouts that are not "infinite" and may exceed
integer type ranges.
Backtrace information was included by commit 35a52bd1b4 (server: add
"ctestInfo" request to get test info, 2017-10-25) to match that already
provided for targets. However, the backtrace representation uses too
much memory and needs to be dropped. Remove it from test information.
Issue: #17502
The backtrace information is very repetitive and hugely increases the
size of the codemodel object. We need to remove it until an alternative
representation can be developed. Revert commit v3.10.0-rc1~393^2
(server: Report backtraces in codemodel response, 2017-06-20), except
for the protocol version number (because it indicates other new things).
Unfortunately this is incompatible with clients that expect the
"crossReferences" field in targets. However, the regression in memory
usage is quite serious, especially on large projects, and therefore
breaks even older clients that do not use backtraces. Since the
"crossReferences" field was only provided by one release (3.10.0), it is
simplest to revert it outright for 3.10.1.
Fixes: #17502
