The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio
generators based on `CMAKE_GENERATOR_PLATFORM` or some default.
Prior to the VS 2019 generator, the default was always `Win32`.
However, for the `Visual Studio 16 2019` generator, the default is
based on the host platform.
Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for
use by project code. This is particularly useful in toolchain files
because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so
`CMAKE_VS_PLATFORM_NAME` is not yet known. Of course the toolchain file
author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not
then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that
will be used.
Fixes: #19177
Since commit 9175a378f5 (QtDialog: Add windows taskbar progress,
2018-11-17, v3.14.0-rc1~330^2) we've added a missing overlay icon.
This results in Windows falling back to a default overlay icon.
Simply drop this line.
Fixes: #19160
For `MACOSX_BUNDLE` targets we generate an `Info.plist` automatically
and add it to the sources presented to Xcode. Avoid mutating the
original target's list of sources to achieve this. Otherwise when we
generate the same target again (e.g. in a sub-project's Xcode file) it
will look different than the first time and possibly break invariants.
Fixes: #19114
The `cmLocalGenerator::GetIncludeDirectoriesImplicit` method is called
by `cmQtAutoGenInitializer` to get the compiler's list of implicit
include directories. Since commit 557b2d6e65 (Fix regression in
-I/usr/include exclusion logic, 2019-02-13, v3.14.0-rc2~6^2~2) the
method hard-codes exclusion of `/usr/include` for historical reasons.
However, it should not be reported as a real implicit include directory
unless the compiler really has it.
Refactor the logic to distinguish the hard-coded exclusion of
`/usr/include` from the real list of implicit include directories.
Fixes: #19100
When the current source file is not found the FilePath variable was left
with the previous path content. In case the previous file had less lines
than the current one and there are 'line' entries for the current one
with higher number we ended up in a buffer overflow while indexing the
previous file entry with a line number higher. By clearing the
FilePath, the empty() guard triggers correctly on an empty path and it
avoid modifying the wrong data.
Any `include_directories()` calls in toolchain files are used during our
ABI detection step even though it does not include any system headers.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2), that check is also used
to detect implicit include directories. Any `include_directories()` in
a toolchain file are detected as implicit and later excluded from
explicit specification on compiler command lines, thus breaking the
purpose of the calls in the first place.
Fix the implicit include directory detection step to avoid using paths
from `include_directories()` calls in the toolchain file.
Fixes: #19079
Do not process interface libraries in ways that expect build information
to be present internally. This filtering was left out of the extra
generator accidentally when interface libraries were introduced, but it
worked by accident until commit 76ad2ecb50 (Order SYSTEM include
directories after non-system directories, 2018-04-13, v3.12.0-rc1~179^2)
added a code path that was not tolerated.
Fixes: #18363
Since commit c76c1ea208 (find_program: Consider CWD only for paths with
separator, 2018-05-31, v3.13.0-rc1~413^2) we accidentally convert the
leading `//` to just `/` on results with Windows network paths.
This was caused by `CollapseCombinedPath` being less robust than
`CollapseFullPath`. Restore use of the latter but in a way that
preserves the requirement of the above commit to support candidates that
are themselves absolute.
Fixes: #19049
Issue: #19050
In commit 57e48f16f2 (VS: Add Visual Studio 16 2019 generator,
2019-01-09, v3.14.0-rc1~150^2) and commit 0fd742a6ff (VS: Teach VS 2019
generator to select host tools matching host arch, 2019-01-28,
v3.14.0-rc1~63^2) we intended to select the `x64` target architecture
and `x64` host tools by default on x64 host machines. Fix detection
of a x64 host when CMake itself is a 32-bit x86 process.
The KWSys SystemInformation `Is64Bits` member is not set correctly,
which led to this bug. Pending investigation on the KWSys side,
simply test ourselves via `IsWow64Process`.
Revert commit da402a081b (VS: Use MSBuild matching toolset host
architecture, 2019-01-28, v3.14.0-rc1~50^2). Multiple people have
reported that the 64-bit `amd64/msbuild` tool fails in cases that the
32-bit `msbuild` works. Drop our change pending further investigation
and hopefully a fix to VS.
Fixes: #18904, #19037
Issue: #18219
Require the word "warning" to appear at the start of a line, after
whitespace, or after a `:`. This is the same that CTest launchers use
to match warnings. It avoids matching "warning" inside file paths.
Fixes: #19019
Since commit e89ad0f94e (install: Allow installing targets created in
another directory, 2018-06-18, v3.13.0-rc1~407^2) the `install(TARGETS)`
command may find a global-scoped target outside the calling directory.
Ignore an `IMPORTED GLOBAL` target if it is found in this way. Imported
targets cannot be installed, and trying to do so violates internal
invariants.
Fixes: #19022
Encode `\n` as ` ` to avoid generating a literal newline inside an
XML attribute. This is more readable and also fixes custom commands in
`.csproj` files with VS 2019 RC.
Fixes: #19001
The Intel Fortran `.vfproj` files do support both Fortran and the
Windows Resource compiler (`.rc)` files. Prior to CMake 3.9 we did not
support that, but commit 2c9f35789d (VS: Decide project type by linker
lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) accidentally enabled it.
It was then broken by commit d3d2c3cd49 (VS: Fix Fortran target type
selection when linking C++ targets, 2019-02-04, v3.14.0-rc1~13^2).
Restore support for Fortran+RC in VS projects and add a test case.
Fixes: #19002
The filter in commit e768d96c74 (CUDA: Filter out host link flags during
device linking, 2018-10-22, v3.13.0-rc2~4^2~2^2) removes `-framework`
but not the framework name that comes after it. Revise the logic to
remove both.
Fixes: #18911
A temporary workaround added by commit 626c51f47b (VS: Update for Visual
Studio 2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) is no longer needed
as of VS 2019 preview 4.
Fixes: #18898
Make sure `std::cbegin`, `std::cend`, and `std::size` work in C++17 or
C++14 mode before choosing the corresponding standard level for
compiling CMake itself. This helps in cases that the compiler is using
a standard library too old to support the full standard level chosen.
In commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to targets,
2019-01-15, v3.14.0-rc1~83^2) all `AddNewTarget` call sites were updated
to copy the directory-level `EXCLUDE_FROM_ALL` into the target property
of the same name, except that the one for `include_external_msproject`
was incorrectly missed. Add it now.
Furthermore, refactoring in commit b99129d2d8 (ENH: some code cleanup,
2007-03-12, v2.6.0~2020) accidentally set the `EXCLUDE_FROM_ALL` target
property of `include_external_msproject`-generated targets to `FALSE`
instead of simply leaving it unset. This was not necessary but had no
effect until the above commit gave it a meaning. Drop that.
Fixes: #18986
The original warning pre-dates support for install components.
There are now legitimate scenarios where an install(TARGETS)
command may list a target that is excluded from all, e.g.
hierarchical projects that will never install the component such a
target belongs to.
Fixes: #18938
Since commit 2e91627dea (ParseImplicitIncludeInfo: add Fortran implicit
include handling, 2019-01-25, v3.14.0-rc1~73^2) we actually populate
`CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES` for the first time. This
value may be useful to project code to pass to other tooling that wants
to preprocess the way Fortran does, so we should compute the value.
However, compilers like `gfortran` do not actually search their own
implicit include directories for `.mod` files. The directories must be
passed via `-I` in order for `.mod` files in them to be found.
Since Fortran has no standard library header files that we need to avoid
overriding, it is safe to *not* filter out implicit include directories
from those passed explicitly via `-I` options. Skip this filtering so
that include directories specified by project code to find `.mod` files
will be searched by the compiler even if they happen to be implicitly
searched by the preprocessor.
Fixes: #18914
