The `FRAMEWORK` target property affects the way the `install()` command
treats the target and so should be set first. Our implementation
assumed that this was always the case and led to an assertion failure.
Prior to CMake 3.12 this was visible only when using an explicit
`LIBRARY ... NAMELINK_ONLY` option, but commit 0212d7c762 (install: add
NAMELINK_COMPONENT argument, 2018-04-18, v3.12.0-rc1~139^2~3) made
it possible with a simple `LIBRARY DESTINATION`.
Fully supporting out-of-order specification will require non-trivial
refactoring to defer install generator creation to generate time.
For now simply restore the old behavior of installing the framework
to the library destination.
Fixes: #18848
Remove now redundant implicit parser code from CrayPrgEnv.cmake, as
this function is now supported in the general cmake code
(e.g. Modules/CMakeParseImplicit{Include,Link}Info.cmake).
This simplifies __CrayPrgEnv_setup() to take only one arg (${lang})
and allows us to remove a level of inclusion as
CrayPrgEnv-${lang}.cmake is now compiler independent we
do not need the CrayPrgEnv-${compiler}-${lang} files any more.
Add implicit include parser for PGI compiler ID. PGI verbose output
for CXX differs from C and Fortran, so CXX is broken out into its own
case. The C and Fortran compilers take "-YI,path" and "-Mnostdinc" to
change or disable the builtin include path. The last arg on the command
line appears to override previous args (e.g. "-YI,path1 -YI,path2" will
set the path to "path2" ... the previous "-YI,path1" gets undone).
The CXX compiler verbose output reports with "-I" rather than "-stdinc"
for the built in path. In addition with CXX "-Mnostdinc" does not
completely zero the include path (e.g. "#include <stdio.h>" still works
with "-Mnostdinc"... "-I/usr/include" still shows up in the verbose output).
Minor adjustments to get the SunPro parser to handle Fortran as well.
Fixes for Cray compiler support (Modules/Compiler/Cray-{C,CXX}.cmake):
The *_COMPILE_OPTION flags contain options like "-h c99,gnu" ...
these options need to be in double quotes (they are currently not).
Otherwise, cmake treats them as lists and tries to run the compiler
with "-h;c99,gnu" and fails when it is "Detecting C compile features"...
Also, the Cray-CXX.cmake contains "__compiler_cray(C)" instead of
"__compiler_cray(CXX)" -- this error prevents the correct VERBOSE
flags for CXX from being defined which prevents the implicit include
parser from running.
Add additional test cases for PGI and SunPro Fortran to the
Tests/RunCMake/ParseImplicitIncludeInfo area.
VS 2017 and VS 2019 provide `amd64/MSBuild.exe` variants next to
their `MSBuild.exe` tools. When the 64-bit host toolchain is
selected (e.g. via `host=x64`), select the 64-bit MSBuild too.
Fixes: #18219
This will allow `CMAKE_GENERATOR_TOOLSET` to influence build tool
selection.
For reference, commit f8cb9944a1 (Find native build tool after
determining the target system, 2017-09-26, v3.10.0-rc1~31^2) already
delayed this step from where it was historically.
On Apple, the implementation of cmGlobalXCodeGenerator::Open uses
LSOpenCFURLRef from CoreServices. This get's transitively pulled in
from CMake's libuv build but ends up generating a linker error when
using an external libuv. This explicitly adds the appropriate
dependency.
While we already support `VERBOSE` environment variable and
`CMAKE_VERBOSE_MAKEFILE` cached variable, add `-v` and `--verbose`
command line options to be able to activate verbose output directly from
CMake's build tool mode command line.
Also make `msbuild` honor the verbosity setting. `xcodebuild` still
doesn't honor the verbosity setting as it will need a policy added
and reworking of cmGlobalGenerator and cmsys to support
multiple command invocation.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07) we now have compiler implicit include
directory computation for gcc and clang. It should be safe now to pass
these to `moc`. This patch re-enables passing the compiler implicit
include directories to `moc`, which was disabled due to issue #18669.
Fixes: #18041
Issue: #18669
Use a dedicated `std::set` for implicit include directories instead
of (ab)using the emitted variable. This in combination with lambdas
makes it easier to comprehend which paths are emitted.
For the implicit include directories we used to omit the
`CMAKE_SYSROOT_COMPILE`/`CMAKE_SYSROOT` prefix. This has been changed and
the implicit paths are returned prefixed. Implicit include directory returning
is only ever used by QtAutoGen which requires prefixed paths. QtAutoGen passes
the (implicit) include paths to the `moc` which isn't aware of
`CMAKE_SYSROOT_COMPILE`/`CMAKE_SYSROOT`.
This patch strips the `stripImplicitDirs` and `appendAllImplicitDirs`
parameters from the `cmLocalGenerator::GetIncludeDirectories` method and makes
it a wrapper into the new `cmLocalGenerator::GetIncludeDirectoriesImplicit`
method. `cmLocalGenerator::GetIncludeDirectoriesImplicit` is the renamed old
implementation of `cmLocalGenerator::GetIncludeDirectories` and still
accepts `stripImplicitDirs` and `appendAllImplicitDirs`.
The motivation is that there's only *one* case where
`cmLocalGenerator::GetIncludeDirectories` is called with the
`stripImplicitDirs` parameter being `false` (QtAutoGen), but many other places
where it is called using the `true` default value.
QtAutoGen is modified to use `cmLocalGenerator::GetIncludeDirectoriesImplicit`
directly. In two use cases of `cmLocalGenerator::GetIncludeDirectories`
the manually set `true` value for `stripImplicitDirs` is removed.
626c51f47b VS: Update for Visual Studio 2019 Preview 2
fd45cbf40e VS: Fix `/MANIFESTUAC:` link flag mapping for v142
db35e3cfd6 VS: Fix support for '/guard:cf' linker flag for v142
533f95c847 VS: Map the link `/debug` flag for v142
d2fcc6748a VS: Fix `/MANIFESTUAC:NO` link flag mapping for v142
a7973ccb53 VS: Populate `/permissive` flag table entry for v142
049410c0b6 VS: Populate `/JMC-` flag table entry for v142
43aa632f57 VS: Populate `-Qspectre-` flag table entry for v142
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2856