The naming convention for submodule files varies across compilers. Add
a table to the compiler information modules and thread the information
through to the Fortran module dependency parser. Fill out the table for
compiler ids known to support Fortran submodules.
Fixes: #18746
The check added by commit 0a29a31161 (VS2017: Verify Windows 8.1 SDK
before using it, 2017-04-25, v3.8.1~2^2) used the wrong path to
`windows.h` within the SDK, leading to it never being detected.
Fixes: #18923
The `cmsys/Enconding.h` include had a typo in its surrounding ifdef,
possibly causing a missing function declaration (`cmsysEncoding_DupToWide`).
As this is C code, this resulted in the code compiling, but with a truncated
return value, possibly causing crashes.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2) the values of the
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` variables are computed from
a real compiler invocation. In this case the paths under the sysroot
should already have the sysroot prefix so we should no longer have to
add the sysroot prefix. However, it is also possible for project code
to add its own paths to `CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES`
without the sysroot prefix and expect the historical addition of the
sysroot prefix to be preserved.
Try to account for both cases by conditionally adding the sysroot prefix
on implicit include directories that do not already have it.
The change in commit 15ad830062 (Refactor exclusion of -I/usr/include to
avoid per-language values, 2019-01-21, v3.14.0-rc1~108^2~4) caused the
exclusion to apply to Fortran, but it was only meant for C, CXX, and
CUDA. The purpose of the change was to prepare for the value of
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` to be computed from the
actual compiler instead of hard-coded. We need to preserve exclusion of
`-I/usr/include` if the compiler has any implicit include directory that
looks intended to replace it, e.g. `<sdk>/usr/include` on macOS.
Fixes: #18914
In commit 1293ed8507 (ParseImplicitIncludeInfo: keep implicit incl.
consistent when rerunning cmake, 2019-01-30, v3.14.0-rc1~26^2) the
`Platform/UnixPaths` module was updated to add `/usr/include` to
`CMAKE_{C,CXX,CUDA}_IMPLICIT_INCLUDE_DIRECTORIES` through an
initialization variable used by `CMakeDetermineCompilerABI` instead of
directly. This approach makes it only a default that can be overridden
by detection of the implicit include directories really used by the
compiler.
The addition of `<sdk>/usr/include` to default implicit include
directories by the `Platform/Darwin` module needs the same update but
was accidentally left out of the original commit.
In CMake 3.13.x, we had this evaluation for if() conditions:
if(a) elseif(b) else(a) endif(a)
The sensible intention of the change in commit c2efb3efcd (Help: Revise
docs on Scripting Commands, 2018-10-16, v3.14.0-rc1~505^2) was:
> "endif", "endfunction" etc: Explain that the argument is optional and
> maintained for compatibility only
Instead of "endif", it ended up being written to the documentation as
"elseif" by the commit author (oops) to if()'s page.
if(a) elseif(a!?) else() endif(a?)
Truthfully, endif()'s parameter should be an optional verbatim repeat
and not elseif()'s. If it wasn't, elseif() would be described to be the
same as if(). The rightful intended description is:
if(a) elseif(b) else() endif()
Fix that typo.
This change adds the Octave::Octinterp target to make the octinterp
library available without users having to resort to using the
Octave_INTERP_LIBRARY variable.
Since commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to
targets, 2019-01-15, v3.14.0-rc1~83^2) we automatically forward the
`EXCLUDE_FROM_ALL` to targets as they are created. This regressed
support for interface libraries on which the property is not allowed.
Skip forwarding the `EXCLUDE_FROM_ALL` property for interface libraries.
It is not needed on them because they do not participate in the
generated build system anyway.
Fixes: #18896
a28caabf45 Autogen: AUTOMOC support for files with the same name but different extensions
1f802295f2 Autogen: Extend the SameName test with same name but different extension files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2920
`CUDA_RESOLVE_DEVICE_SYMBOLS` can be used with shared, module, and
executable target types. This relaxation is to allow for better
interoperability with linkers that automatically do CUDA device symbol
resolution and have no way to disable it.
