CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-03-13T14:02:08-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/19037VS: CMake doesn't detect VS2019 Preview 4.1 SVC12023-03-13T14:02:08-04:00drivehappyVS: CMake doesn't detect VS2019 Preview 4.1 SVC1I'm running CMake version `3.14.0-rc4` against `Visual Studio 2019 Preview 4.1 SVC1`, both are at the latest version currently. When generating, I'm running into the general error of:
```
No CMAKE_C_COMPILER could be found.
```
I'm using...I'm running CMake version `3.14.0-rc4` against `Visual Studio 2019 Preview 4.1 SVC1`, both are at the latest version currently. When generating, I'm running into the general error of:
```
No CMAKE_C_COMPILER could be found.
```
I'm using the following commandline: `cmake -G "Visual Studio 16 2019" -A x64 ..\glfw-3.2.1`
In particular, it seems to have issues finding the Universal CRT (snippet from CMakeError.log):
```
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.20.27404\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1104: cannot open file 'ucrtd.lib' [C:\dev\glfw-build\CMakeFiles\3.14.0-rc4\CompilerIdC\CompilerIdC.vcxproj]
Done Building Project "C:\dev\glfw-build\CMakeFiles\3.14.0-rc4\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED.
```
My Windows SDKs are installed in the default location of `C:\Program Files (x86)\Windows Kits\10`, and I have the following versions installed:
* 10.0.10240.0
* 10.0.16299.0
* 10.0.17763.0
All of these have the ucrtd.lib (and ucrt.lib) present in their `lib/%version%/ucrt/x64` folders. I've checked the VS installer to ensure that the "Windows Universal C Runtime", as well as the v141 and v142 Toolsets for x64/x86 are installed as well.
I'm seeing this occur against different CMake projects, particularly I tested against [GLFW](https://www.glfw.org/). I've also tried fully uninstalling VS2019 and installing again to no avail.
I've attached the CMake build output here: [glfw-build.zip](/uploads/ff5a4f10f2cd77ef38f6d448a51f856d/glfw-build.zip)
Note: When generating for VS 2017 (which is also installed) with cmake `3.14.0-rc4`, it succeeds. I've not been able to get any prior CMake 3.14.0 preview versions to work with any VS2019 preview versions, so this hasn't been a regression AFAIK.
Note2: Running under the VS2019 Developer Command Prompt doesn't seem to make a difference.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19022CMake crashes when installing export of an imported library target2019-03-12T11:49:53-04:00Lassi NiemistöCMake crashes when installing export of an imported library targetThe following code creates segmentation fault on Ubuntu 14.04, using CMake 3.13 or 3.14.0-rc{1,2,3}.
```
project(link_dir_test C)
cmake_minimum_required(VERSION 3.14)
add_library(libfootarget SHARED IMPORTED GLOBAL)
set_target_propertie...The following code creates segmentation fault on Ubuntu 14.04, using CMake 3.13 or 3.14.0-rc{1,2,3}.
```
project(link_dir_test C)
cmake_minimum_required(VERSION 3.14)
add_library(libfootarget SHARED IMPORTED GLOBAL)
set_target_properties(libfootarget PROPERTIES IMPORTED_LOCATION /usr/lib/libzip.so)
install(TARGETS libfootarget DESTINATION bin/ EXPORT syssw-export)
```
3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19019Configure failure: Feature check fails because it matches username by accident2019-03-08T07:31:40-05:00mwarningConfigure failure: Feature check fails because it matches username by accidentRunning `./configure` gives me this:
```
-- Checking if compiler supports needed C++17 constructs
-- Checking if compiler supports needed C++17 constructs - yes
-- Checking if compiler supports C++ make_unique
-- Checking if compiler sup...Running `./configure` gives me this:
```
-- Checking if compiler supports needed C++17 constructs
-- Checking if compiler supports needed C++17 constructs - yes
-- Checking if compiler supports C++ make_unique
-- Checking if compiler supports C++ make_unique - no
-- Checking if compiler supports C++ unique_ptr
-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
See also "/home/mwarning/cmake/CMakeFiles/CMakeOutput.log".
See also "/home/mwarning/cmake/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
```
The cause is this line:
```
if(check_output MATCHES "[Ww]arning")
```
(https://github.com/Kitware/CMake/blob/master/Source/Checks/cm_cxx_features.cmake#L30)
... and my username is part of the path in the output.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19006downgrade from `cmake-3.14.0-rc2-win64-x64.msi` to `cmake-3.13.2-win64-x64.ms...2019-03-13T10:08:09-04:00Andreydowngrade from `cmake-3.14.0-rc2-win64-x64.msi` to `cmake-3.13.2-win64-x64.msi` removes /bin directoryHave tried to downgrade to test an issue and found this.
Needs to run the installer again to repair the missed directory.
OS: Windows 7 x64
The same issue found for: `3.13.2` -> `3.12.3` -> `3.11.2`
For the `3.11.2` -> `3.10.0-rc3`:
t...Have tried to downgrade to test an issue and found this.
Needs to run the installer again to repair the missed directory.
OS: Windows 7 x64
The same issue found for: `3.13.2` -> `3.12.3` -> `3.11.2`
For the `3.11.2` -> `3.10.0-rc3`:
the directory is not removed, but `cmake.exe` executable is absent
For the `3.10.0-rc3` -> `3.9.1` -> `3.14.0-rc3`:
the issue is NOT present
3.14.0https://gitlab.kitware.com/cmake/cmake/-/issues/19002VS: Mixing Fortran and RC in one target no longer works2019-03-04T08:35:50-05:00Brad KingVS: Mixing Fortran and RC in one target no longer worksThis example:
```
cmake_minimum_required(VERSION 3.9)
project(TestFortran Fortran)
add_executable(testF testF.f90 testRC.rc)
```
is useful because `.vfproj` files actually do support Fortran+RC together. This was not yet intended to w...This example:
```
cmake_minimum_required(VERSION 3.9)
project(TestFortran Fortran)
add_executable(testF testF.f90 testRC.rc)
```
is useful because `.vfproj` files actually do support Fortran+RC together. This was not yet intended to work but !643 made it work accidentally. It was not noticed and so was not added to our test suite.
!2913 regressed the support.
We should restore the behavior and add a test case.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19001CSharp: VS 2019 fails RunCMake.CSharpCustomCommand test2019-03-07T09:16:00-05:00Brad KingCSharp: VS 2019 fails RunCMake.CSharpCustomCommand testIn a build tree of CMake itself with VS 2019 preview 4 or the RC, running the test via `ctest -C Debug -R RunCMake.CSharpCustomCommand -V` fails with:
```
Generating test.cs
Invalid parameter to SETLOCAL command
...
C:\...\Tests\R...In a build tree of CMake itself with VS 2019 preview 4 or the RC, running the test via `ctest -C Debug -R RunCMake.CSharpCustomCommand -V` fails with:
```
Generating test.cs
Invalid parameter to SETLOCAL command
...
C:\...\Tests\RunCMake\CSharpCustomCommand\CommandWithOutput-build\CSharpCustomCommand.csproj(88,5): error MSB3073: The command "setlocal "C:\...\bin\cmake.exe" -E copy_if_different ..." exited with code 1.
```
The actual `.csproj` file on disk contains:
```xml
<Exec Command="echo Generating test.cs" />
<Exec Command="setlocal
"C:\...\bin\cmake.exe" -E copy_if_different ...
..." />
```
which looks correct, but running MSBuild fails as above.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19000ExternalProject setting STAMP_DIR doesn't guide log location anymore2019-03-01T09:08:18-05:00Robert MaynardExternalProject setting STAMP_DIR doesn't guide log location anymoreStarting in 3.14 `ExternalProject` the `LOG_DIR` option was added to control the location of log files. The documentation states that if `STAMP_DIR` is set, and not `LOG_DIR` than the log files are placed in the `STAMP_DIR` location. Thi...Starting in 3.14 `ExternalProject` the `LOG_DIR` option was added to control the location of log files. The documentation states that if `STAMP_DIR` is set, and not `LOG_DIR` than the log files are placed in the `STAMP_DIR` location. This is not the case, instead they are placed in the default `STAMP_DIR` location, and not the user provided location.
example cmake code:
```cmake
cmake_minimum_required(VERSION 3.14.0)
include(ExternalProject)
externalproject_add(
vtkm
GIT_REPOSITORY "https://github.com/robertmaynard/vtk-m"
GIT_TAG "bdcb76cadbf8a949473d6"
INSTALL_DIR "${CMAKE_BINARY_DIR}/install"
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}/install
DOWNLOAD_DIR downloads
SOURCE_DIR vtkm/src
BINARY_DIR vtkm/build
STAMP_DIR vtkm/stamp
LOG_DOWNLOAD ON
LOG_CONFIGURE ON
LOG_BUILD ON
)
```
When we look at the contents on disk we see `vtkm-prefix/src/vtkm-stamp/` being used for the log files not `vtkm/stamp/`:
```
~/W/m/t/e/build $ ls -l vtkm
total 12
drwxr-xr-x 8 robert robert 4096 Feb 28 16:21 build/
drwxr-xr-x 10 robert robert 4096 Feb 28 16:21 src/
drwxr-xr-x 2 robert robert 4096 Feb 28 16:26 stamp/
~/W/m/t/e/build $ ls -l vtkm/stamp/
total 20
-rw-r--r-- 1 robert robert 1998 Feb 28 16:21 vtkm-build-.cmake
-rw-r--r-- 1 robert robert 0 Feb 28 16:21 vtkm-configure
-rw-r--r-- 1 robert robert 2182 Feb 28 16:21 vtkm-configure-.cmake
-rw-r--r-- 1 robert robert 0 Feb 28 16:21 vtkm-download
-rw-r--r-- 1 robert robert 2112 Feb 28 16:21 vtkm-download-.cmake
-rw-r--r-- 1 robert robert 69 Feb 28 16:21 vtkm-gitclone-lastrun.txt
-rw-r--r-- 1 robert robert 69 Feb 28 16:21 vtkm-gitinfo.txt
-rw-r--r-- 1 robert robert 0 Feb 28 16:21 vtkm-mkdir
-rw-r--r-- 1 robert robert 0 Feb 28 16:21 vtkm-patch
~/W/m/t/e/build $ ls -l vtkm-prefix/src/vtkm-stamp/
total 28
-rw-r--r-- 1 robert robert 361 Feb 28 16:26 vtkm-build-err.log
-rw-r--r-- 1 robert robert 15443 Feb 28 16:26 vtkm-build-out.log
-rw-r--r-- 1 robert robert 0 Feb 28 16:21 vtkm-configure-err.log
-rw-r--r-- 1 robert robert 949 Feb 28 16:21 vtkm-configure-out.log
-rw-r--r-- 1 robert robert 536 Feb 28 16:21 vtkm-download-err.log
-rw-r--r-- 1 robert robert 0 Feb 28 16:21 vtkm-download-out.log
```3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18990FindPython doesn't create Python2::Python target when configuring during buil...2019-02-27T08:09:50-05:00ArtalusFindPython doesn't create Python2::Python target when configuring during build (Windows, 3.14 rc2)First encountered at my colleague's PC at work, then reproduced by myself at home. MWE:
```
cmake_minimum_required(VERSION 3.12)
project(xxx)
find_package(Python2 COMPONENTS Development REQUIRED)
if(NOT TARGET Python2::Python)
mess...First encountered at my colleague's PC at work, then reproduced by myself at home. MWE:
```
cmake_minimum_required(VERSION 3.12)
project(xxx)
find_package(Python2 COMPONENTS Development REQUIRED)
if(NOT TARGET Python2::Python)
message(FATAL_ERROR "NOT FOUND")
endif()
add_library(x x.cpp)
```
If I change CMakeLists and do a simple configure via `cmake .` - everything is OK. However, if I change it and do `cmake --build .` instead -- there will be no target `Python2::Python`. Other find-modules seem to work just fine.
Happens to me only with 3.14 rc2 on Windows -- on ArchLinux I couldn't reproduce it neither with pre-built binaries from the website, nor with `cmake-git` AUR package. Downgrading to 3.13.4 on Windows fixes the problem.3.14.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/18988FindOctave should not include "octave" in `Octave_INCLUDE_DIR`2021-01-13T03:45:53-05:00Daniele E. DomenichelliFindOctave should not include "octave" in `Octave_INCLUDE_DIR`On my system (debian testing + CMake master) the `FindOctave` module sets the `Octave_INCLUDE_DIR` to `/usr/include/octave-4.4.1/octave`. This folder should be `/usr/include/octave-4.4.1` instead. The same issue is inherited by the `Octa...On my system (debian testing + CMake master) the `FindOctave` module sets the `Octave_INCLUDE_DIR` to `/usr/include/octave-4.4.1/octave`. This folder should be `/usr/include/octave-4.4.1` instead. The same issue is inherited by the `Octave::Octave` target.
As far as I know, typically the files from octave are included passing the `octave` folder. For example, files generated by [Swig](http://www.swig.org/) include the files in this way:
```c++
#include <octave/oct.h>
#include <octave/version.h>
```
These file, at the moment, do not compile with the `Octave::Octave` target.
I recommend to fix this before CMake 3.14 final release, because this folders contains files like `version.h`, `error.h`, `utils.h` and more, that are very likely to cause conflicts. Also if people starts using it, it will be harder later to change it, keeping the compatibility and avoiding at the same time the conflicts.3.14.0https://gitlab.kitware.com/cmake/cmake/-/issues/18987Minimum CMake version to build CMake itself increased to 3.72019-02-27T07:54:27-05:00Craig ScottMinimum CMake version to build CMake itself increased to 3.7As [reported](https://cmake.org/pipermail/cmake/2019-February/069090.html) on the mailing list, CMake itself currently requires at least CMake 3.7 due to the use of `VERSION_GREATER_EQUAL` in an `if()` condition in `Tests/RunCMake/CMakeL...As [reported](https://cmake.org/pipermail/cmake/2019-February/069090.html) on the mailing list, CMake itself currently requires at least CMake 3.7 due to the use of `VERSION_GREATER_EQUAL` in an `if()` condition in `Tests/RunCMake/CMakeLists.txt`:
```cmake
if ((CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0.24215.1 AND
CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.10) OR
CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.10.25017)
```
This should probably use `NOT ... VERSION_LESS` instead to allow earlier CMake versions to be used. The above appears to have been added by a5dd159990e.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18986EXCLUDE_FROM_ALL changes lead to overly aggressive include_external_msproject...2019-02-27T07:56:03-05:00Craig ScottEXCLUDE_FROM_ALL changes lead to overly aggressive include_external_msproject() dependency behaviorThis problem was [originally reported](https://cmake.org/pipermail/cmake/2019-February/069088.html) on the CMake users mailing list, pasting in the essentials here for easier reference.
## Original problem description
We have a fairly ...This problem was [originally reported](https://cmake.org/pipermail/cmake/2019-February/069088.html) on the CMake users mailing list, pasting in the essentials here for easier reference.
## Original problem description
We have a fairly large CMake project which uses
include_extenal_msproject() when we are producing Visual Studio
solutions to bring in projects produced using another build metadata
generator. We've noticed most of our Visual Studio builds have started
failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
3.13.4 and 3.14.0-rc2 this issue was introduced).
An example of how the behavior differs can be realised with the
following example:
*dependencies/CMakeLists.txt:*
```cmake
# several duplications of the following block exist replacing fooN with
foo1, foo2, foo3, etc.
add_library(fooN_cmake STATIC IMPORTED GLOBAL)
if(MSVC)
include_external_msproject(fooN_cmake_extern "fooN.vcproj")
else()
# other external things happen here using ExternalProject_add to end
up creating fooN_cmake_extern for non-VS/non-Windows builds.
endif()
add_dependencies(fooN_cmake fooN_cmake_extern)
set_property(TARGET fooN_cmake PROPERTY INTERFACE_INCLUDE_DIRECTORIES "path to foo include files")
set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG "path to foo static library")
# ... more properties possibly set
```
*frontend1/CMakeLists.txt:*
```cmake
add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" EXCLUDE_FROM_ALL)
add_executable(frontend1 main.c)
target_link_libraries(frontend1 foo1_cmake foo2_cmake)
```
*frontend2/CMakeLists.txt:*
```cmake
add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" EXCLUDE_FROM_ALL)
add_executable(frontend2 main.c)
target_link_libraries(frontend2 foo3_cmake foo2_cmake)
```
**The old behavior:** we could invoke CMake using a source directory of
frontend1 or frontend2 to get Visual Studio solutions. Only the Visual
Studio projects which are imported using include_extenal_msproject()
that are dependencies of that particular frontend are included in the
solution i.e. the VS solution for frontend1 will not include foo3_cmake
as part of the build at all. I expect this due to the use of
EXCLUDE_FROM_ALL.
**The new behavior:** all frontends will include every single project
defined using include_extenal_msproject that CMake encounters. They will
all attempt to be built regardless of if there is a dependency. I would
only have expected this behavior if EXCLUDE_FROM_ALL was *not* set when
using add_subdirectory().
## Follow-up comment
I've verified that the revision you pointed me to
(24b6e4830d9027e63db7dfafa500aaeb652d3a4c) is where the behavior broke
(I built CMake using the revision directly before this one and
everything still works fine). I'm no expert with CMake development -
could someone chime in on whether what I am seeing is expected or
whether something has inadvertently been broken?
Testing this is actually quite simple. There is no need to even have
valid external vcproj files on the file system - CMake does not appear
to care if they exist or not when generating the solution. The most
trivial test I can give to reproduce the behavior is:
*./CMakeLists.txt:*
```cmake
cmake_minimum_required(VERSION 3.4)
project(frontend_test)
add_subdirectory(deps "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" EXCLUDE_FROM_ALL)
add_executable(frontend1 main.c)
target_link_libraries(frontend1 foo1_cmake)
```
*./main.c:*
```c
/* nothing - unimportant for the test */
```
*./deps/CMakeLists.txt:*
```cmake
cmake_minimum_required(VERSION 3.4)
add_library(foo1_cmake STATIC IMPORTED GLOBAL)
include_external_msproject(foo1_cmake_extern "foo1.vcproj")
add_dependencies(foo1_cmake foo1_cmake_extern)
set_property(TARGET foo1_cmake PROPERTY IMPORTED_LOCATION_DEBUG "foo1.lib")
add_library(foo2_cmake STATIC IMPORTED GLOBAL)
include_external_msproject(foo2_cmake_extern "foo2.vcproj")
add_dependencies(foo2_cmake foo2_cmake_extern)
set_property(TARGET foo2_cmake PROPERTY IMPORTED_LOCATION_DEBUG "foo2.lib")
```
Invoking CMake before revision 24b6e4830d9027e63db7dfafa500aaeb652d3a4c
and opening the solution will show that Visual Studio would like to open
foo1_cmake_extern (and it will show as unavailable in the solution
explorer on account of the file not actually existing).
Invoking CMake at or after revision
24b6e4830d9027e63db7dfafa500aaeb652d3a4c and opening the solution will
show that Visual Studio would like to open foo1_cmake_extern AND
foo2_cmake_extern (and both will show as unavailable in the solution
explorer on account of the file not actually existing).3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18984FindThreads: Bad check for pthread_kill2019-11-16T00:05:58-05:00Stephan SzaboFindThreads: Bad check for pthread_killcommit e9a1ddc5 changed the `CHECK_SYMBOL_EXISTS` for pthread_create in FindThreads to pthread_kill in pthread.h. However, it seems that pthread_kill is supposed to be defined in signal.h not pthread.h.
I'm not sure if it's more correct...commit e9a1ddc5 changed the `CHECK_SYMBOL_EXISTS` for pthread_create in FindThreads to pthread_kill in pthread.h. However, it seems that pthread_kill is supposed to be defined in signal.h not pthread.h.
I'm not sure if it's more correct to look for a different symbol or to look for this one in signal.h.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18983VS: Using '-T llvm' through llvm.vsix does report clang-cl as compiler2019-02-27T07:55:16-05:00Leonardo SantagadaVS: Using '-T llvm' through llvm.vsix does report clang-cl as compilerTrying to use the CMAKE_GENERATOR_TOOLSET command line option (-T) with llvm cmake still uses cl.exe as a compiler and link.exe as a linker during its tests (also cl.exe as the assembler).Trying to use the CMAKE_GENERATOR_TOOLSET command line option (-T) with llvm cmake still uses cl.exe as a compiler and link.exe as a linker during its tests (also cl.exe as the assembler).3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18955CMP0083 PIE policy warnings for executables are noisy2024-01-11T15:28:28-05:00Craig ScottCMP0083 PIE policy warnings for executables are noisyOpening this issue to discuss CMP0083 after trying out CMake 3.14.0-rc2 on some larger projects. It is likely to be common for projects to set CMAKE_POSITION_INDEPENDENT_CODE to true, which will act as a default for all targets. In the p...Opening this issue to discuss CMP0083 after trying out CMake 3.14.0-rc2 on some larger projects. It is likely to be common for projects to set CMAKE_POSITION_INDEPENDENT_CODE to true, which will act as a default for all targets. In the past, this worked well and ensured that even if you built static libraries, those could be linked in by shared libraries and the shared library was able to be PIC. Because we didn't have PIE linker flags correct, executables simply came out as non-PIE but no warning was generated. It was not explicit that they should have been PIE anyway.
With CMake 3.14, we now try to make an executable PIE if its POSITION_INDEPENDENT_CODE target property is set to NEW **and** we also require the project to have called `check_pie_supported()` from the new `CheckPIESupported` module, which was also introduced in 3.14. If CMP0083 is unset (which will generally be the case, at least in the medium term for many projects), having CMAKE_POSITION_INDEPENDENT_CODE set to true will now start warning about every executable, even test code. This is very noisy and the choices a project faces for reducing the noise are currently not very attractive:
* Stop defining CMAKE_POSITION_INDEPENDENT_CODE and manually set POSITION_INDEPENDENT_CODE on all the libraries where it might be relevant. This could be a lot of work and might not even be something that a project can do (it may not be able to do it for all of its dependencies, for example). If we rely on this, then we are basically saying to stop using CMAKE_POSITION_INDEPENDENT_CODE altogether.
* Explicitly set the policy to NEW and accept that executables that may not need to be PIE will become PIE. Tests don't typically need to be, for example, but they would become PIE with this strategy. The performance cost of PIE seems to be small from what I understand (I've seen numbers like 2% thrown around back when researching the merge request for the PIE work), but I don't know if that's always going to be representative. I'm also not sure whether it will always be possible to force the CMP0083 policy to NEW down through dependencies without resorting to fairly hacky methods (e.g. setting the CMAKE_POLICY_DEFAULT_CMP0083 variable to NEW), since the policy will get reset with every `cmake_minimum_required()` call.
Since the `CheckPIESupported` module is being introduced in the same CMake version and therefore no existing project would be using it, I wonder if we could use that module as an added condition on whether we issue a warning or not. If the `check_pie_supported()` function hasn't been called, then assume the project never intended for executables to be PIE and just leave the behavior at that with no warning. If that function *has* been called, that function enforces that CMP0083 must be set to NEW at the point of that call and we know at that point that *something* in the project actively wants to have PIE support. Unfortunately, we still get defeated by `cmake_minimum_required()` resetting our CMP0083 policy again, so such a change would only be of benefit until something somewhere in the build started enabling PIE executables by calling `check_pie_supported()`, but I suspect that's still a pretty significant proportion of projects.3.14.0Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/18944Using Android NDK zlib breaks system include ordering2019-02-18T14:50:01-05:00Gregor JasnyUsing Android NDK zlib breaks system include orderingHello,
The following test case disturbs system include path ordering of Android NDK r16:
```cmake
cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
project(testcase CXX)
file(WRITE testcase.cpp "#include <iostream>")
add_library(testca...Hello,
The following test case disturbs system include path ordering of Android NDK r16:
```cmake
cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
project(testcase CXX)
file(WRITE testcase.cpp "#include <iostream>")
add_library(testcase STATIC testcase.cpp)
find_package(ZLIB REQUIRED)
target_link_libraries(testcase PRIVATE ZLIB::ZLIB)
```
Error:
```
/home/gregorj/Android/android-ndk-r16b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=aarch64-none-linux-android --gcc-toolchain=/home/gregorj/Android/android-ndk-r16b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot=/home/gregorj/Android/android-ndk-r16b/sysroot -isystem /home/gregorj/Android/android-ndk-r16b/sysroot/usr/include -isystem /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include -isystem /home/gregorj/Android/android-ndk-r16b/sources/android/support/include -isystem /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/include -isystem /home/gregorj/Android/android-ndk-r16b/sysroot/usr/include/aarch64-linux-android -funwind-tables -no-canonical-prefixes -D__ANDROID_API__=21 -fexceptions -frtti -g -fPIC -std=gnu++14 -MD -MT CMakeFiles/testcase.dir/testcase.cpp.o -MF CMakeFiles/testcase.dir/testcase.cpp.o.d -o CMakeFiles/testcase.dir/testcase.cpp.o -c ../testcase.cpp
In file included from ../testcase.cpp:1:
In file included from /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include/iostream:40:
In file included from /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include/istream:163:
In file included from /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include/ostream:140:
/home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include/locale:807:12: error: use of undeclared identifier 'strtof_l'
return strtof_l(__a, __p2, _LIBCPP_GET_C_LOCALE);
^
/home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include/locale:813:12: error: use of undeclared identifier 'strtod_l'; did you mean 'strtold_l'?
return strtod_l(__a, __p2, _LIBCPP_GET_C_LOCALE);
^
/home/gregorj/Android/android-ndk-r16b/sysroot/usr/include/stdlib.h:237:13: note: 'strtold_l' declared here
long double strtold_l(const char* __s, char** __end_ptr, locale_t __l) __INTRODUCED_IN(21);
^
2 errors generated.
```
Before adding zlib the order was:
```
-isystem /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include
-isystem /home/gregorj/Android/android-ndk-r16b/sources/android/support/include
-isystem /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/include
-isystem /home/gregorj/Android/android-ndk-r16b/sysroot/usr/include
-isystem /home/gregorj/Android/android-ndk-r16b/sysroot/usr/include/aarch64-linux-android
```
After adding zlib the order is as follows:
```
-isystem /home/gregorj/Android/android-ndk-r16b/sysroot/usr/include
-isystem /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++/include
-isystem /home/gregorj/Android/android-ndk-r16b/sources/android/support/include
-isystem /home/gregorj/Android/android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/include
-isystem /home/gregorj/Android/android-ndk-r16b/sysroot/usr/include/aarch64-linux-android
```
I guess `zlib.h` living in `/home/gregorj/Android/android-ndk-r16b/sysroot/usr/include` affects include order.
My CMake command line is:
`~/src/cmake/_build/bin/cmake -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/home/gregorj/Android/android-ndk-r16b -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a -DCMAKE_SYSTEM_VERSION=21 -DCMAKE_ANDROID_STL_TYPE=c++_static -DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang ..`
Thanks,
Gregor3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18941Don't call 'nasm /?' at cmake call time.2019-04-30T11:18:18-04:00Sergei TrofimovichDon't call 'nasm /?' at cmake call time.The bug is originally reported as:
- https://bugs.gentoo.org/670944
- https://bugzilla.nasm.us/show_bug.cgi?id=3392529
- https://github.com/libjpeg-turbo/libjpeg-turbo/issues/332
The problem:
cmake calls `nasm` with unsupported `/?`...The bug is originally reported as:
- https://bugs.gentoo.org/670944
- https://bugzilla.nasm.us/show_bug.cgi?id=3392529
- https://github.com/libjpeg-turbo/libjpeg-turbo/issues/332
The problem:
cmake calls `nasm` with unsupported `/?` option. On some versions of nasm this leads to '/?' file to be created. In a sandboxed environment this triggers out-of-sandbox access violation and build failure.
It looks like the problem stems from https://github.com/libjpeg-turbo/libjpeg-turbo/blob/4f943644e5bf7544f126ce1d23e430e649a82c41/simd/CMakeLists.txt#L41 where `enable_language(ASM_NASM)` is called.
`nasm` maintainer suggests not to pass unsupported arguments to nasm.
`libjpeg-turbo` maintainer suggests it's a `cmake` deficiency.
Thanks!3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18938Overly pessimistic warning on a target with EXCLUDE_FROM_ALL set and install ...2019-02-25T07:49:57-05:00Craig ScottOverly pessimistic warning on a target with EXCLUDE_FROM_ALL set and install rule definedWith the changes in CMake 3.14.0-rc2, presumably from !2816, I'm now seeing warnings like the following in our projects:
```
WARNING: Target "gmock" has EXCLUDE_FROM_ALL set and will not be built by default but an install rule has been ...With the changes in CMake 3.14.0-rc2, presumably from !2816, I'm now seeing warnings like the following in our projects:
```
WARNING: Target "gmock" has EXCLUDE_FROM_ALL set and will not be built by default but an install rule has been provided for it. CMake does not define behavior for this case.
```
The above warning does not consider all scenarios where the EXCLUDE_FROM_ALL directory property is set before pulling in something with `add_subdirectory()`. A project may do this but then only select the install components it is interested in for packaging, specifically excluding those install components that the above warning is talking about. We do this for almost all of our projects and the behavior is well-defined in the sense that because we don't ask for these targets to be installed in our packages, we don't open ourselves up to the sort of undefined behavior the warning mentions. This makes the warning overly pessimistic.3.14.0Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/18936error: 'asm/types.h' file not found for Android build with CMake 3.14.0 RC2 (...2019-02-19T07:55:00-05:00Steve Robinsonerror: 'asm/types.h' file not found for Android build with CMake 3.14.0 RC2 (RC1 was fine)After installing CMake 3.14.0 RC2, I get this build error when building an Android library:
android-ndk-r18b/sysroot/usr/include/linux/types.h:21:10: fatal error: 'asm/types.h' file not found
This happens on my Macbook and inside a dock...After installing CMake 3.14.0 RC2, I get this build error when building an Android library:
android-ndk-r18b/sysroot/usr/include/linux/types.h:21:10: fatal error: 'asm/types.h' file not found
This happens on my Macbook and inside a docker container, which is defined in this repo:
https://gitlab.com/ssrobins/docker-android-build
Both environments use Android NDK r18b.
If I go back to CMake 3.14.0 RC1, I don't get the error.
To reproduce this, do the following:
1. Either use the Dockerfile to set up the docker container defined here, https://gitlab.com/ssrobins/docker-android-build/blob/master/Dockerfile, or follow the install steps outlined in the Dockerfile on a Mac.
1. git clone https://gitlab.com/ssrobins/sdl2-example.git
1. From the main repo directory, run: sh ./build_android.sh. This will run cmake to generate the makefiles and do the build.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18927VS: Unable to choose Windows 8.1 SDK version in VS 16 20192020-09-11T12:26:28-04:00Brad KingVS: Unable to choose Windows 8.1 SDK version in VS 16 2019Work in !2962 and discussion in #18923 identified that when no `WindowsTargetPlatformVersion` is written to a `.vcxproj` file then VS 2019 chooses "10.0 latest" instead of "8.1" as VS 2017 did.
This means that an explicit value may be n...Work in !2962 and discussion in #18923 identified that when no `WindowsTargetPlatformVersion` is written to a `.vcxproj` file then VS 2019 chooses "10.0 latest" instead of "8.1" as VS 2017 did.
This means that an explicit value may be needed in order to get 8.1.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18923VS: Unable to choose 8.1 SDK version in VS 152019-02-15T07:29:09-05:00Dedmen MillerVS: Unable to choose 8.1 SDK version in VS 15It seems like it's currently impossible to make CMake use the Windows 8.1 SDK when building on a Windows 10 host system with VS14 or above.
I tried forcing CMake to use the 8.1 SDK by doing
```
if (${CMAKE_HOST_SYSTEM_NAME} STREQUAL "Wi...It seems like it's currently impossible to make CMake use the Windows 8.1 SDK when building on a Windows 10 host system with VS14 or above.
I tried forcing CMake to use the 8.1 SDK by doing
```
if (${CMAKE_HOST_SYSTEM_NAME} STREQUAL "Windows")
set (CMAKE_SYSTEM_VERSION 8.1 CACHE TYPE INTERNAL FORCE) #Force 8.1 SDK, to keep it compatible with win7
endif()
```
I tried `6.3`, `7`, `8`, `8.1` values and each one always chose the latest installed SDK version being `10.0.17763.0`
The code `cmGlobalVisualStudio14Generator::GetWindows10SDKVersion` only checks for windows 10 SDK versions.
The code compares the version here
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGlobalVisualStudio14Generator.cxx#L313 <br>
And correctly has "8.1" in the `this->SystemVersion` but because the windows 8.1 SDK is not inside `sdks` it will never be checked and it will fallback to the latest SDK on L320.
If I just cheat and insert a `sdks.emplace_back("8.1");` in L307, then it correctly creates a vcxproj with Windows SDK version set to 8.1 exactly like I need.
I have also tried to do
`set(CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION "8.1")`
and
`set (CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION 8.1 CACHE TYPE INTERNAL FORCE)`
before/after the `project()` definition, and also at the far end of my CMakeList.<br>
This caused no effect (project is built with `10.0.17763.0` SDK).
I need to build applications that have to be backwards compatible till windows 7, the latest windows 10 SDK however links the dll/executable against functions in windows libraries that simply don't exist on win 7/8.
Seems like I'm not alone with that problem. https://social.msdn.microsoft.com/Forums/en-US/fcbf7b3f-9548-47ea-bb38-03d10eb6bfbb/how-to-select-the-windows-sdk-81-when-using-cmake-in-visual-studio-2017?forum=visualstudiogeneral3.14.0Brad KingBrad King