CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-11-26T08:56:40-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/20018FindODBC: Test fails with Clang/LLVM-MinGW toolchain2019-11-26T08:56:40-05:00Cristian AdamFindODBC: Test fails with Clang/LLVM-MinGW toolchainThe [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain fails on Windows with `FindODBC` module from 3.16.0rc4 in two ways:
1. The module searches for `sql.h`, and finds it in `c:\llvm-mingw\include` which ends up as be...The [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain fails on Windows with `FindODBC` module from 3.16.0rc4 in two ways:
1. The module searches for `sql.h`, and finds it in `c:\llvm-mingw\include` which ends up as being as `ODBC_INCLUDE_DIR`. The problems is that this is the `MinGW` toolchain path, which ends up having `-system` and it comes before Clang include paths.
`c:\llvm-mingw\include` contains `math.h` which causes problems if it's included before the Clang counterpart.
2. `find_library` for `odbc32` will return `c:\windows\system32\odbc32.dll`, which is not supported by Clang's `lld`.
CMake's `Tests/FindODBC` fails with:
```
Internal cmake changing into directory: C:/Projects/cmake/test-odbc/FindODBC/Test
======== CMake output ======
The C compiler identification is Clang 9.0.0
Check for working C compiler: C:/llvm-mingw/bin/cc.exe
Check for working C compiler: C:/llvm-mingw/bin/cc.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Found ODBC: C:/Windows/System32/odbc32.dll
Configuring done
Generating done
Build files have been written to: C:/Projects/cmake/test-odbc/FindODBC/Test
======== End CMake output ======
Change Dir: C:/Projects/cmake/test-odbc/FindODBC/Test
Run Clean Command:c:/Tools/Ninja/ninja.exe clean
[1/1 79.4/sec]Cleaning all built files...
Cleaning... 0 files.
Run Build Command(s):c:/Tools/Ninja/ninja.exe && [1/4 1.5/sec]Building C object CMakeFiles/test_odbc_tgt.dir/main.c.obj
[2/4 2.7/sec]Building C object CMakeFiles/test_odbc_var.dir/main.c.obj
[3/4 3.8/sec]Linking C executable test_odbc_tgt.exe
FAILED: test_odbc_tgt.exe
cmd.exe /C "cd . && C:\llvm-mingw\bin\cc.exe -O3 -DNDEBUG CMakeFiles/test_odbc_tgt.dir/main.c.obj -o test_odbc_tgt.exe -Wl,--out-implib,libtest_odbc_tgt.dll.a -Wl,--major-image-version,0,--minor-image-version,0 C:/Windows/System32/odbc32.dll C:/Windows/System32/odbccp32.dll -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
lld-link: error: C:/Windows/System32/odbc32.dll: bad file type. Did you specify a DLL instead of an import library?
lld-link: error: C:/Windows/System32/odbccp32.dll: bad file type. Did you specify a DLL instead of an import library?
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
[4/4 4.8/sec]Linking C executable test_odbc_var.exe
FAILED: test_odbc_var.exe
cmd.exe /C "cd . && C:\llvm-mingw\bin\cc.exe -O3 -DNDEBUG CMakeFiles/test_odbc_var.dir/main.c.obj -o test_odbc_var.exe -Wl,--out-implib,libtest_odbc_var.dll.a -Wl,--major-image-version,0,--minor-image-version,0 C:/Windows/System32/odbc32.dll C:/Windows/System32/odbccp32.dll -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
lld-link: error: C:/Windows/System32/odbc32.dll: bad file type. Did you specify a DLL instead of an import library?
lld-link: error: C:/Windows/System32/odbccp32.dll: bad file type. Did you specify a DLL instead of an import library?
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```
Qt6 uses for it's odbc plugin `find_package(ODBC)` which makes the build fail with Clang/LLVM-MinGW toolchain.
One workaround is to provide a custom `FindODBC.cmake` or fix this upstream.3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/20007CTest: Resource allocation spec file versioning2019-11-26T09:12:41-05:00Brad KingCTest: Resource allocation spec file versioningA thread [on discourse](https://discourse.cmake.org/t/208) pointed out that as of CMake 3.16.0-rc4 we did not consider versioning of the `ctest --resource-spec-file <spec>` file.A thread [on discourse](https://discourse.cmake.org/t/208) pointed out that as of CMake 3.16.0-rc4 we did not consider versioning of the `ctest --resource-spec-file <spec>` file.3.16.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/20005FindxwWidgets: throws error "WX_FIND_LIBS Macro invoked with incorrect argume...2019-11-25T09:38:17-05:00Andreas MartinFindxwWidgets: throws error "WX_FIND_LIBS Macro invoked with incorrect arguments"Trying to build my project using wxWidgets with
```cmake
find_package(wxWidgets REQUIRED COMPONENTS core base)
```
Throws an error:
```
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindwxWidgets.cmake:650 (WX_FIND_LI...Trying to build my project using wxWidgets with
```cmake
find_package(wxWidgets REQUIRED COMPONENTS core base)
```
Throws an error:
```
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindwxWidgets.cmake:650 (WX_FIND_LIBS):
WX_FIND_LIBS Macro invoked with incorrect arguments for macro named:
WX_FIND_LIBS
Call Stack (most recent call first):
CMakeLists.txt:47 (find_package)
```
(Windows 10, 64bit, MSVC Pro 2015)
Regards, Andreas3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20002Repeated path for internal generated unity build object files (single config ...2019-11-26T08:55:25-05:00Craig ScottRepeated path for internal generated unity build object files (single config generators only)Basically the same problem as in #19952 except this time for unity builds.Basically the same problem as in #19952 except this time for unity builds.3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19998Xcode generator doesn't set correct explicitFileType based on LANGUAGE for Ob...2019-11-21T11:27:32-05:00Tobias HietaXcode generator doesn't set correct explicitFileType based on LANGUAGE for Objective-C++ filesHello!
I noticed another issue with the Objective-C++ support and the Xcode generator. It turns out that the Xcode generator doesn't seem to care about the LANGUAGE property on source files.
I have the following CMakeLists.txt:
...Hello!
I noticed another issue with the Objective-C++ support and the Xcode generator. It turns out that the Xcode generator doesn't seem to care about the LANGUAGE property on source files.
I have the following CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.16 FATAL_ERROR)
project(test-objc C CXX OBJCXX)
add_executable(hello hello.cpp)
set_source_files_properties(hello.cpp PROPERTIES LANGUAGE OBJCXX)
```
This works fine with Ninja and Makefiles but not with Xcode - the file is not built at all.
I traced it down to the `explicitFileType` being set to `sourcecode`:
```
3DE340914549401FBA1AD8F4 /* /Users/tobias/Code/objc-xcode/hello.cpp */ = {isa = PBXFileReference; explicitFileType = sourcecode; fileEncoding = 4; name = hello.cpp; path = hello.cpp; sourceTree = SOURCE_ROOT; }
```
I can get around this by setting: `XCODE_EXPLICIT_FILE_TYPE sourcecode.cpp.objcpp` on the source file so it's not a breaking bug. But it seems like maybe CMake should handle this case.
I think the problem is here:
https://gitlab.kitware.com/cmake/cmake/blob/v3.16.0-rc4/Source/cmGlobalXCodeGenerator.cxx#L941
This switch statement probably need to check for objective-c and objective-c++.3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19987CTest: Resource allocation does not combine instances to reach requested slot...2019-11-26T09:12:42-05:00Craig ScottCTest: Resource allocation does not combine instances to reach requested slot totalsThe current behavior of the resource allocation logic does not allow multiple array items from a resource type to be combined to satisfy the needs of a single resource group. Consider the following:
```cmake
set_property(TEST someTest P...The current behavior of the resource allocation logic does not allow multiple array items from a resource type to be combined to satisfy the needs of a single resource group. Consider the following:
```cmake
set_property(TEST someTest PROPERTY RESOURCE_GROUPS gpus:4)
```
With a resource spec file defined like so:
```
{
"local": [
{
"gpus" : [
{
"id": "0",
"slots": 2
},
{
"id": "1",
"slots": 2
}
]
}
]
}
```
The `ctest` scheduler sees that the test's resource group requires 4 slots of `gpus`. The resource spec file provides 4 slots, but they are split across two elements of the `gpus` resource type array. The scheduler refuses to merge slots from different array elements and the test fails to run with the current scheduler logic. However, the *Environment Variables* section of the `ctest(1)` manual includes the following example for the `CTEST_RESOURCE_GROUP_<num>_<resource-type>` environment variable:
```
CTEST_RESOURCE_GROUP_0_GPUS=id:0,slots:2
CTEST_RESOURCE_GROUP_1_GPUS=id:2,slots:2
CTEST_RESOURCE_GROUP_2_GPUS=id:1,slots:4;id:3,slots:1 <-- Not possible to get this
CTEST_RESOURCE_GROUP_2_CRYPTO_CHIPS=id:card0,slots:2
```
The line highlighted can't actually be generated with the current scheduler behavior. It is merging slots from multiple array elements and assigning them to a single group. Either the example is incorrect, or the scheduler logic is restricted in a way that wasn't expected.3.16.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/19979CMake 3.16 breaks our NSIS installer customizations2019-11-18T09:51:05-05:00Brad DavisCMake 3.16 breaks our NSIS installer customizationsWe recently updated our CI servers with CMake 3.16rc3 and discovered that the installers produced by the builds were no longer valid. Specifically, we use an NSIS.template.in file in our source repository to customize the installer by a...We recently updated our CI servers with CMake 3.16rc3 and discovered that the installers produced by the builds were no longer valid. Specifically, we use an NSIS.template.in file in our source repository to customize the installer by adding some new pages to the installer wizard with options to create desktop icons and launch the application after install.
When building with CMake 3.16rc3, these customization do not appear in the resulting installer. When building with 3.15.5, they do appear.
Our project is at https://github.com/highfidelity/hifi but the build process is complex and the NSIS installer requires a number of plugins, so it's not suitable as an easy test project to demonstrate the problem. If I can find the time I will attempt to make a much smaller self-contained example.3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19970Clarify REUSE_FROM behavior of target_precompile_headers()2019-11-18T09:46:35-05:00Craig ScottClarify REUSE_FROM behavior of target_precompile_headers()I'm updating the docs for PCH, as discussed in https://gitlab.kitware.com/cmake/cmake/issues/19953#note_652323. In cleaning up the wording while I'm there, I noticed that if you use the second signature of `target_precompile_headers()` w...I'm updating the docs for PCH, as discussed in https://gitlab.kitware.com/cmake/cmake/issues/19953#note_652323. In cleaning up the wording while I'm there, I noticed that if you use the second signature of `target_precompile_headers()` which has the `REUSE_FROM` keyword, the result of calling that sets not just the target's `PRECOMPILE_HEADERS_REUSE_FROM` property, it also sets its `PRECOMPILE_HEADERS` property. Was that intended? I only noticed because if I tried to invoke the `REUSE_FROM` form on the same target twice, the warning I get is the following:
```
PRECOMPILE_HEADERS property is already set on target ("myapp")
```
I was expecting only `PRECOMPILE_HEADERS_REUSE_FROM` to be set as a result of the call, but this error talks about `PRECOMPILE_HEADERS` instead. Some quick checking confirmed that `PRECOMPILE_HEADERS` is indeed populated by the call. @cristianadam Can you clarify the intended behavior of this? I'll then incorporate that into my doc updates.3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19964testOptional failing with 3.16.0-rc32019-11-18T10:42:26-05:00Orion PoplawskitestOptional failing with 3.16.0-rc3Testing out builds of the cmake Fedora package on Fedora rawhide using 3.16.0-rc3 and getting a new test case failure:
```
test 267
Start 267: CMakeLib.testOptional
267: Test command: /builddir/build/BUILD/cmake-3.16.0-rc3/build/...Testing out builds of the cmake Fedora package on Fedora rawhide using 3.16.0-rc3 and getting a new test case failure:
```
test 267
Start 267: CMakeLib.testOptional
267: Test command: /builddir/build/BUILD/cmake-3.16.0-rc3/build/Tests/CMakeLib/CMakeLibTests "testOptional"
267: Test timeout computed to be: 1500
257/554 Test #267: CMakeLib.testOptional ............................Child aborted***Exception: 1.28 sec
```
This is with ctest -V -j4.3.16.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/19955CMake bundles vulnerable copy of Expat - please update to (2.2.8 or) 2.2.92022-02-18T22:09:34-05:00Sebastian PippingCMake bundles vulnerable copy of Expat - please update to (2.2.8 or) 2.2.9Please update the outdated vulnerable copy of Expat 2.2.7 at [Utilities/cmexpat/lib](https://gitlab.kitware.com/cmake/cmake/tree/master/Utilities/cmexpat/lib). Please check the [change log of Expat](https://github.com/libexpat/libexpat/b...Please update the outdated vulnerable copy of Expat 2.2.7 at [Utilities/cmexpat/lib](https://gitlab.kitware.com/cmake/cmake/tree/master/Utilities/cmexpat/lib). Please check the [change log of Expat](https://github.com/libexpat/libexpat/blob/master/expat/Changes) for more details.
Thank you!
Related: #16997 #17138 #194373.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19953INTERFACE_PRECOMPILE_HEADERS seems questionable2020-07-24T20:18:49-04:00Craig ScottINTERFACE_PRECOMPILE_HEADERS seems questionableLooking at the current docs for the PCH feature and searching back through the mail archives for the historical discussions around its evolution (back to 2012, thanks to @purpleKarrot!), I'm questioning the wisdom of supporting INTERFACE...Looking at the current docs for the PCH feature and searching back through the mail archives for the historical discussions around its evolution (back to 2012, thanks to @purpleKarrot!), I'm questioning the wisdom of supporting INTERFACE behavior for precompiled headers. The `INTERFACE_...` properties are generally meant to be about usage requirements, but precompiled headers can never be a usage requirement. The code should always be able to be built just fine without them (this has been stated explicitly in the history of the feature's evolution). PCH is only a build *optimisation*.
A target cannot know all the different ways that its consumers might want to use PCH. If a dependency target sets an `INTERFACE_PRECOMPILE_HEADERS` property, then *every* source file in the consuming target will now be exposed to all of those headers' contents, whether they are needed or not. In the worst case, it could break the consuming target if there are symbol clashes. I had the unfortunate recent experience in real world projects where heavily used dependencies defined symbols they shouldn't have in their headers, so we had to carefully minimise the places those headers were included to avoid those symbols clashing with other things. If those heavily used dependencies had elected to use a feature like what `INTERFACE_PRECOMPILE_HEADERS` seeks to offer, we would have to resort to manually clearing that property just to be able to link to that target, or disabling PCH for our own target altogether.
I'd be interested if there's a genuine use case that provides strong motivation for `INTERFACE_PRECOMPILE_HEADERS`. About the only potential use case I've seen mentioned so far is for header-only libraries, but they can't rely on PCH because it might not be available/supported everywhere, so again it can't be a requirement, only an optimisation.
If there is no strong argument for `INTERFACE_PRECOMPILE_HEADERS`, I'd have to reluctantly suggest that we may want to pull this property from the 3.16.0 release until we can convince ourselves it actually makes sense. To be clear, the `PRECOMPILE_HEADERS` property is fine, I'm only talking here about `INTERFACE_PRECOMPILE_HEADERS`.3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19952Repeated path for internal generated PCH files (single config generators only)2020-01-16T11:06:40-05:00Craig ScottRepeated path for internal generated PCH files (single config generators only)For single config generators only, when a target enables precompiled headers, the path into which the pch file is generated ends up being the following:
```
CMakeFiles/targetName.dir/CMakeFiles/targetName.dir
```
The repeated pattern l...For single config generators only, when a target enables precompiled headers, the path into which the pch file is generated ends up being the following:
```
CMakeFiles/targetName.dir/CMakeFiles/targetName.dir
```
The repeated pattern looks like an error, but after some digging, it appears to be an unfortunate side effect of generating the `cmake_pch.hxx.cxx` file in `${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/targetName.dir` instead of in `${CMAKE_CURRENT_BINARY_DIR}`. Using Ninja for illustration, the code [here](https://gitlab.kitware.com/cmake/cmake/blob/v3.16.0-rc3/Source/cmNinjaTargetGenerator.cxx#L343-346) assumes that `CMakeFiles/targetName.dir` has to be prepended to the object name (I think the Makefile equivalent is [here](https://gitlab.kitware.com/cmake/cmake/blob/adf863f15e348789e4d20e3d2dd792f35d4f4725/Source/cmMakefileTargetGenerator.cxx#L405-410)). The single-config PCH handling code [here](https://gitlab.kitware.com/cmake/cmake/blob/adf863f15e348789e4d20e3d2dd792f35d4f4725/Source/cmGeneratorTarget.cxx#L3363-3380) masks this by repeating the pattern as well.
The path repetition makes the path unnecessarily long, which may cause issues on some systems. I see a couple of ways to avoid this:
* Generate a target-specific file at `${CMAKE_CURRENT_BINARY_DIR}/<targetName>_pch.hxx.cxx` instead of the generically named `cmake_pch.hxx.cxx` in `${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/targetName.dir`. Then all the usual assumptions about prepending/appending paths for object files will result in non-repetition.
* Update the implementation of the single config generators to recognise this situation somehow and not repeat the path.
Of the two, the first option seems less invasive but makes the assumption that the generated file won't clash with anything. The second option has more risk, since it could affect more than just PCH code.3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19946UNITY_BUILD ignores HEADER_FILE_ONLY source file property2019-11-12T09:51:24-05:00Craig ScottUNITY_BUILD ignores HEADER_FILE_ONLY source file propertyIf a source file already has the `HEADER_FILE_ONLY` source property set to true, that source file should be excluded from the unity build. As of CMake 3.16.0-rc3, this is not the case. A simple demonstrator project that verifies the issu...If a source file already has the `HEADER_FILE_ONLY` source property set to true, that source file should be excluded from the unity build. As of CMake 3.16.0-rc3, this is not the case. A simple demonstrator project that verifies the issue:
*CMakeLists.txt:*
```cmake
cmake_minimum_required(VERSION 3.16)
project(unitybuild)
set(CMAKE_UNITY_BUILD YES)
add_library(checker ok1.cpp ok2.cpp notOk.cpp)
set_source_files_properties(notOk.cpp PROPERTIES HEADER_FILE_ONLY TRUE)
```
*ok1.cpp*
```c++
#define ok1_added 1
int ok1() { return 23; } // Just to ensure there's something to compile, prevents warnings
```
*ok2.cpp*
```c++
#define ok2_added 1
int ok2() { return 57; } // Just to ensure there's something to compile, prevents warnings
```
*notOk.cpp*
```c++
#if defined(ok1_added) || defined(ok2_added)
#error Was not excluded from unity build
#endif
int notOk() { return 3; } // Just to ensure there's something to compile, prevents warnings
```3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19940PCH: precompiled header with generator expression generates wrong/invalid inc...2019-11-08T10:36:37-05:00phwissmannPCH: precompiled header with generator expression generates wrong/invalid include when using angle bracketsUsing target_precompile_headers with a generator expression will produce invalid include.
```
target_precompile_headers(some_target
$<$<BOOL:True>:<header>>
$<$<BOOL:False>:<header>>
)
```
will produce
```
#include <header>
#inclu...Using target_precompile_headers with a generator expression will produce invalid include.
```
target_precompile_headers(some_target
$<$<BOOL:True>:<header>>
$<$<BOOL:False>:<header>>
)
```
will produce
```
#include <header>
#include ">"
```
This happens in cmake3.16.0-rc33.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19936OBJC/OBJCXX flags don't get set for Xcode generator2019-11-18T10:33:33-05:00Craig ScottOBJC/OBJCXX flags don't get set for Xcode generatorThe following minimal project can be used to demonstrate the problem described further below:
*CMakeLists.txt:*
```cmake
cmake_minimum_required(VERSION 3.15)
project(objctest LANGUAGES C CXX OBJC OBJCXX)
# Uncomment one of these two co...The following minimal project can be used to demonstrate the problem described further below:
*CMakeLists.txt:*
```cmake
cmake_minimum_required(VERSION 3.15)
project(objctest LANGUAGES C CXX OBJC OBJCXX)
# Uncomment one of these two commands
#string(APPEND CMAKE_OBJCXX_FLAGS " -fobjc-arc")
add_compile_options(-fobjc-arc)
add_library(myfuncs STATIC myfuncs.mm)
```
The contents of `myfuncs.mm` are relatively unimportant, it's the actual command line used to compile it that matter. But for completeness, you can use the following as confirmation that the flag was present:
*myfuncs.mm:*
```c++
#if ! __has_feature(objc_arc)
#error THIS CODE MUST BE COMPILED WITH ARC ENABLED!
#endif
```
Using the Ninja or Makefiles generator, the `-fobjc-arc` compiler option is added to the command line, whereas with the Xcode generator, it isn't. Further investigation shows that it seems like none of the methods that normally work for modifying compiler flags are working for the Xcode generator when the OBJC and OBJCXX languages are enabled. Neither target properties nor CMake variables like `CMAKE_OBJCXX_FLAGS` seem to have any effect and are ignored. This breaks projects that previously worked without the OBJC or OBJCXX languages enabled.3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/199343.16 regression in FindBinUtils.cmake when used with cross compile toolchain2019-11-08T09:41:13-05:00Vedran Vujinovic3.16 regression in FindBinUtils.cmake when used with cross compile toolchainThere is a regression introduced in 3.16 with the way FindBinUtils.cmake detects utilities when used with cross compile toolchain.
The utilities, not overridden in the toolchain file, will be detected from the PATH instead of the toolcha...There is a regression introduced in 3.16 with the way FindBinUtils.cmake detects utilities when used with cross compile toolchain.
The utilities, not overridden in the toolchain file, will be detected from the PATH instead of the toolchain provided ones.
The regression seems to be introduced with https://gitlab.kitware.com/cmake/cmake/merge_requests/3854.
Here is a quick reproduction with Android NDK r20 toolchain and this sample CMakeLists.txt:
```cmake
project(foo)
message(STATUS "CMake version: ${CMAKE_VERSION}")
message(STATUS "_CMAKE_TOOLCHAIN_PREFIX: ${_CMAKE_TOOLCHAIN_PREFIX}")
message(STATUS "_CMAKE_TOOLCHAIN_SUFFIX: ${_CMAKE_TOOLCHAIN_SUFFIX}")
message(STATUS "CMAKE_C_COMPILER: ${CMAKE_C_COMPILER}")
message(STATUS "CMAKE_CXX_COMPILER: ${CMAKE_CXX_COMPILER}")
message(STATUS "CMAKE_AR: ${CMAKE_AR}")
message(STATUS "CMAKE_LINKER: ${CMAKE_LINKER}")
message(STATUS "CMAKE_RANLIB: ${CMAKE_RANLIB}")
message(STATUS "CMAKE_STRIP: ${CMAKE_STRIP}")
message(STATUS "CMAKE_NM: ${CMAKE_NM}")
message(STATUS "CMAKE_OBJCOPY: ${CMAKE_OBJCOPY}")
message(STATUS "CMAKE_OBJDUMP: ${CMAKE_OBJDUMP}")
message(STATUS "CMAKE_READELF: ${CMAKE_READELF}")
message(STATUS "CMAKE_DLLTOOL: ${CMAKE_DLLTOOL}")
message(STATUS "CMAKE_ADDR2LINE: ${CMAKE_ADDR2LINE}")
```
With **CMake 3.15.5** we get the following output:
```
# cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=/opt/android/ndk/android-ndk-r20/build/cmake/android.toolchain.cmake ../
-- ANDROID_PLATFORM not set. Defaulting to minimum supported version
16.
-- Check for working C compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-- Check for working C compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
-- Check for working CXX compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMake version: 3.15.5
-- _CMAKE_TOOLCHAIN_PREFIX: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
-- _CMAKE_TOOLCHAIN_SUFFIX:
-- CMAKE_C_COMPILER: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-- CMAKE_CXX_COMPILER: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
-- CMAKE_AR: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ar
-- CMAKE_LINKER: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ld
-- CMAKE_RANLIB: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ranlib
-- CMAKE_STRIP: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-strip
-- CMAKE_NM: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-nm
-- CMAKE_OBJCOPY: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy
-- CMAKE_OBJDUMP: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objdump
-- CMAKE_READELF:
-- CMAKE_DLLTOOL:
-- CMAKE_ADDR2LINE:
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/cmake_findbinutils_regression/build
```
With **CMake 3.16.0rc3**:
```
# cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=/opt/android/ndk/android-ndk-r20/build/cmake/android.toolchain.cmake ../
-- ANDROID_PLATFORM not set. Defaulting to minimum supported version
16.
-- Check for working C compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-- Check for working C compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
-- Check for working CXX compiler: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMake version: 3.16.0-rc3
-- _CMAKE_TOOLCHAIN_PREFIX: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
-- _CMAKE_TOOLCHAIN_SUFFIX:
-- CMAKE_C_COMPILER: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-- CMAKE_CXX_COMPILER: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
-- CMAKE_AR: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ar
-- CMAKE_LINKER: /usr/bin/ld
-- CMAKE_RANLIB: /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ranlib
-- CMAKE_STRIP: /usr/bin/strip
-- CMAKE_NM: /usr/bin/nm
-- CMAKE_OBJCOPY: /usr/bin/objcopy
-- CMAKE_OBJDUMP: /usr/bin/objdump
-- CMAKE_READELF: /usr/bin/readelf
-- CMAKE_DLLTOOL: CMAKE_DLLTOOL-NOTFOUND
-- CMAKE_ADDR2LINE: /usr/bin/addr2line
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/cmake_findbinutils_regression/build
```
The problem comes from query for program path, in [CMakeFindBinUtils.cmake](https://gitlab.kitware.com/cmake/cmake/blob/v3.16.0-rc3/Modules/CMakeFindBinUtils.cmake#L76), which doesn't give priority to program names with toolchain prefix anymore.
The way program path is queried at the moment, we get for example:
```
# /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -print-prog-name=objcopy
/usr/bin/objcopy
```
But when we use toolchain prefix, we get the correct path, e.g.:
```
# /opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -print-prog-name=arm-linux-androideabi-objcopy
/opt/android/ndk/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objcopy
```3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19928Check for working ObjC compiler not working when building for iOS2019-11-11T11:45:39-05:00Tobias HietaCheck for working ObjC compiler not working when building for iOSHello,
Ran into this problem with CMake 3.16 (SHA: `g3c0a317`) when trying to build for iOS ARM64:
```
-- The C compiler identification is Clang 8.0.1
-- The CXX compiler identification is Clang 8.0.1
-- Check for working C compiler: /...Hello,
Ran into this problem with CMake 3.16 (SHA: `g3c0a317`) when trying to build for iOS ARM64:
```
-- The C compiler identification is Clang 8.0.1
-- The CXX compiler identification is Clang 8.0.1
-- Check for working C compiler: /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang
-- Check for working C compiler: /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang++
-- Check for working CXX compiler: /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The OBJC compiler identification is Clang 8.0.1
-- The OBJCXX compiler identification is Clang 8.0.1
-- Check for working OBJC compiler: /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang
-- Check for working OBJC compiler: /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang -- broken
CMake Error at /Users/tobias/.conan_plex/.conan/data/cmake/3.16.0-3c0a317a-1/plex/stable/package/b9cf9bf841aca97ce334c83f6fb7c40f3bd8db7d/share/cmake-3.16/Modules/CMakeTestOBJCCompiler.cmake:57 (message):
The Objective-C compiler
"/Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/tobias/Code/plex-media-server/build/CMakeFiles/CMakeTmp
Run Build Command(s):/Users/tobias/.conan_plex/.conan/data/ninja/1.8.2-e234a7bd-6/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/ninja cmTC_a7b16 && [1/2] Building OBJC object CMakeFiles/cmTC_a7b16.dir/testOBJCCompiler.m.o
[2/2] Linking OBJC executable cmTC_a7b16
FAILED: cmTC_a7b16
: && /Users/tobias/.conan_plex/.conan/data/clang/8.0.1-71-0/plex/stable/package/0b647f069fa6c3d1e66c05f0cc32933e0ff5e065/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.0.sdk -mios-version-min=8.0 -arch arm64 -stdlib=libc++ -Wl,-no_weak_imports CMakeFiles/cmTC_a7b16.dir/testOBJCCompiler.m.o -o cmTC_a7b16 && :
ld: warning: ignoring file CMakeFiles/cmTC_a7b16.dir/testOBJCCompiler.m.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64
Undefined symbols for architecture arm64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:35 (enable_language)
-- Configuring incomplete, errors occurred!
See also "/Users/tobias/Code/plex-media-server/build/CMakeFiles/CMakeOutput.log".
See also "/Users/tobias/Code/plex-media-server/build/CMakeFiles/CMakeError.log".
```
This works for iOS x86_64 (using the simulator). So something doesn't seem to be forwarded. It also works for C/C++ as you see above. Not sure what could cause this - the command line above looks correct.
Attached the CMakeOutput and CMakeError files as well.
[CMakeError.log](/uploads/a86e611f8b915b0db4ca8a3885225938/CMakeError.log)
[CMakeOutput.log](/uploads/42181a440b07b738c1a5726ec4e53567/CMakeOutput.log)3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19927CMake 3.16-rc3 with the Xcode generator generates invalid entry for CMakeList...2019-11-11T07:13:45-05:00Remy JetteCMake 3.16-rc3 with the Xcode generator generates invalid entry for CMakeLists.txtI gave a try with CMake 3.16-rc3 on one of our projects, and noticed that when I viewed the generated .xcodeproj in the Xcode IDE each target had a weird empty entry that when opened, stated “The file couldn’t be opened because you don’t...I gave a try with CMake 3.16-rc3 on one of our projects, and noticed that when I viewed the generated .xcodeproj in the Xcode IDE each target had a weird empty entry that when opened, stated “The file couldn’t be opened because you don’t have permission to view it.”
Here’s a screenshot from trying to build googletest:
![69973d19228e085527c261ff9f525d4f892905c4_2_1035x504_1_](/uploads/66ce0698cfd5ed554f7347f522ddafa8/69973d19228e085527c261ff9f525d4f892905c4_2_1035x504_1_.jpeg)
This is happening in each project I’ve tried, and note the blank entries where you’d normally see a CMakeLists.txt.
Looking in the generated project.pbxproj, I notice a weird entry in the PBXGroup section:
FCC28A7F74264D458770B641 /* gtest */ = {
isa = PBXGroup;
children = (
BF1EA80837A243D48244B25D /* Source Files */,
A820BC1E8A784BAFB1E02AA9,
);
name = gtest;
sourceTree = "<group>";
};
Also note that the above hash points to a broken entry in the PBXFileReferenceSection:
A820BC1E8A784BAFB1E02AA9 = {isa = PBXFileReference; explicitFileType = sourcecode; fileEncoding = 4; name = ""; path = ""; sourceTree = SOURCE_ROOT; };
Compare that to the same project in CMake 3.15.4:
PBXGroup
A41D9DD3481542C7A0523855 /* gtest */ = {
isa = PBXGroup;
children = (
283C4B2C019A4C44AE0E5379 /* Source Files */,
4E8A6F14AAD84ED990C56B02 /* /Users/remyjette/src/googletest/googletest/CMakeLists.txt */,
);
name = gtest;
sourceTree = "<group>";
};
and PBXFileReference
4E8A6F14AAD84ED990C56B02 /* /Users/remyjette/src/googletest/googletest/CMakeLists.txt */ = {isa = PBXFileReference; explicitFileType = sourcecode.text; fileEncoding = 4; name = CMakeLists.txt; path = googletest/CMakeLists.txt; sourceTree = SOURCE_ROOT; };3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19926Need to set `-ObjC++` in CMAKE_OBJCXX_FLAGS2019-11-07T10:24:42-05:00Tobias HietaNeed to set `-ObjC++` in CMAKE_OBJCXX_FLAGSIn our project we have some ObjC++ files that ends with the extension `.cpp` (they are actually C++ on non Mac platforms). To handle this with the recent changes we set the `LANGUAGE` property on these files. Unfortunately this causes cl...In our project we have some ObjC++ files that ends with the extension `.cpp` (they are actually C++ on non Mac platforms). To handle this with the recent changes we set the `LANGUAGE` property on these files. Unfortunately this causes clang still to treat these files as C++. I was able to fix this by doing this:
`set(CMAKE_OBJCXX_FLAGS "${CMAKE_OBJCXX_FLAGS} -ObjC++")`
But the question is if this should maybe be done by CMake instead?3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19924macOS: cmake.org distribution needs to codesign executables in bin2020-05-06T03:57:01-04:00ewmailingmacOS: cmake.org distribution needs to codesign executables in binUsing CMake 3.16.0rc1.
I noticed you codesigned and notarized the CMake.app which is great.
However, I noticed that the tools in the bin/ subdirectory (cmake, ccmake, cpack, ctest) are not signed at all. (cmake-gui was signed)
I believe...Using CMake 3.16.0rc1.
I noticed you codesigned and notarized the CMake.app which is great.
However, I noticed that the tools in the bin/ subdirectory (cmake, ccmake, cpack, ctest) are not signed at all. (cmake-gui was signed)
I believe these should also be signed with the hardened runtime enabled.
I caught this because I was testing redistributing CMake with my own stuff inside a big DMG. When I submitted to Apple for notarization, it gave me warnings about these. Apple is supposedly going to clamp down harder in Jan 2020 to require the hardened runtime to be enabled, so I'm worried these might become more problematic then.
But at the very least, it doesn't hurt anything to properly codesign these executables along with everything else.3.16.0Brad KingBrad King