The PGI ( and NVIDIA HPC ) compilers default C++ standard level
are based on the GCC system headers it is compiling against.
Therefore on newer platforms the default C++ level will be >= 11
and requesting C++98 compilation mode will fail as no explicit
flag will be set.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo test discovery when they match exactly.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo detection when they match exactly.
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) uses a different way of writing
out the step scripts and updating time stamps when steps are executed.
That inadvertently always wrote out the scripts for custom commands,
even when the contents didn't change. This caused their timestamp to
always be updated, resulting in those steps always being seen as
out-of-date and needing to be re-executed.
The way timestamps were checked to determine whether to re-execute
a step also did not adequately account for file systems which only have
second-resolution timestamps. The IS_NEWER_THAN if condition also
returns true when timestamps are the same, so one needs to use the
negative form to get a true "is newer than" test.
ExternalProject is not susceptible to this problem because it uses
file(GENERATE) to write out the script files and that only updates the file's
timestamp if the contents change. It also mostly leaves timestamp
checking to the build tool.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo downloads when they match exactly.
The NAG Fortran compiler's `-mdir` flag sets the module output
directory but does not add the directory to the search path for using
modules. This is inconsistent with other compilers like the GNU Fortran
compiler's `-J` flag that does both. In order to make these consistent,
add the module output directory with a `-I` flag on the NAG Fortran
compiler so that it will be searched when using modules too.
We already do this for the XL Fortran compiler since commit 210b0b99a9
(XL: Fix using Fortran modules from their output directory, 2020-02-28,
v3.18.0-rc1~640^2~1).
c9244f369a IntelLLVM: Make explicit Fortran preprocessing under Ninja more robust
056d4bf528 Merge branch 'backport-intel-fortran-preprocess'
af074c266e Intel: Make explicit Fortran preprocessing under Ninja more robust
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5826
c9244f369a IntelLLVM: Make explicit Fortran preprocessing under Ninja more robust
056d4bf528 Merge branch 'backport-intel-fortran-preprocess'
af074c266e Intel: Make explicit Fortran preprocessing under Ninja more robust
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5826
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Issue: #21828
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Fixes: #21828
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) contained a typo which resulted
in any PATCH_COMMAND being ignored. Fix the typo and add a test case
that would have caught the regression.
Some of the things are set in Platform/NVIDIA-CUDA and since we aren't setting
them to different values there's no point in overriding them.
Also fixed an unset() copy-paste error.
Since commit fb2afef620 (CUDA: Support nvcc symlinking to ccache,
2021-01-07) and commit 3cef91a321 (CUDA: Always extract CUDA Toolkit
root from nvcc verbose output, 2021-02-03) we always run the command
`nvcc -v __cmake_determine_cuda` to look for the toolkit root in its
stderr. On Windows, that command may print to stdout instead, so
capture that as well.
This can be confusing if there are autotools and CMake-built GDAL builds
within the same environment as the autotools variant will always be
preferred.
Brad King