They are unused, but if someone used them they would lead to
problems since they would copy the internal raw pointers
and the destructor would cause double delete
d80ecba5c2 Fortran: Fix submodule file names across compilers
72057d9c15 Fortran: Thread compiler id through to internal Fortran parser
7ae329e2ed Fortran: Factor out .mod and .smod file name construction
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Michael Hirsch, Ph.D. <michael@scivision.co>
Merge-request: !2958
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
6fc3382944 Update logic for sysroot in detected implicit include directories
2ad14ef4ea cmAlgorithms: Add cmHasPrefix to match existing cmHasSuffix
557b2d6e65 Fix regression in -I/usr/include exclusion logic
017598a444 macOS: Fix addition of <sdk>/usr/include to default implicit include dirs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2957
ec13bd5230 Tests: Disable test that builds KWSys if not also building CMake
ded4bc136e Merge branch 'upstream-KWSys' into update-kwsys
f3999a21c8 KWSys 2019-02-12 (44676809)
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2953
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.
If `CMake_TEST_EXTERNAL_CMAKE` is enabled then the compiler with which
we are driving tests may not be able to compile CMake, so do not try
to compile KWSys with it either.
091afa7342 Tests: Teach tests when to treat clang-cl as MSVC
006768903c Work around clang-cl breakage on make_unique/std::forward
d625dfcdf9 Avoid compiling CMake itself as C++17 with Clang's MSVC ABI
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2573
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.
Rather than taking a number of out parameters for the various names,
create a structure that is reused for both `GetLibraryNames` and
`GetExecutableNames`. Replace uses according to the new interface.
* Disable the system include unused variable test in ExportImport when
clang is in MSVC compatible mode.
* Disable CxxDialect testcase when clang is in MSVC compatible mode, as
it doesn't support `typeof`.
* Teach Module.WriteCompilerDetectionHeader to treat clang-cl as MSVC.
* Disable the SystemIncludeDirectories testcase within
IncludeDirectories when clang is in MSVC compatible mode.
* Disable the CMakeOnly.CheckCXXCompilerFlag testcase when clang is in
MSVC compatible mode.
* Treat clang-cl as MSVC in LinkOptions.cmake in the try_run and
try_compile testcases.
Clang on Windows with the MSVC ABI produces link errors of the
form `unresolved std::_Iosb<int>::{app,_Openmode} in ...`.
Use a temporary variable to forward as lvalue rather than rvalue
to work around the problem.
GUID functions in ATL cause compilation errors with this compiler.
Add the offending case to our check for C++17 support so that it
is not used by default when it does not work.
