CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-04-12T10:41:15-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17144find_path/find_library behaviour changed between 3.8.2 and 3.9.02018-04-12T10:41:15-04:00Attila Krasznahorkayfind_path/find_library behaviour changed between 3.8.2 and 3.9.0Hi,
We (ATLAS Experiment, http://cern.ch/atlas) have just discovered an extremely inconvenient change in the behaviour of CMake with 3.9.0. Attached is an example ([PathSearchOrder.tar.bz2](/uploads/ecc09400ef0372fea67381b77de6a35f/Path...Hi,
We (ATLAS Experiment, http://cern.ch/atlas) have just discovered an extremely inconvenient change in the behaviour of CMake with 3.9.0. Attached is an example ([PathSearchOrder.tar.bz2](/uploads/ecc09400ef0372fea67381b77de6a35f/PathSearchOrder.tar.bz2) ) demonstrating the issue. (Sorry for the relatively complex example, I tried to simplify it a bit, but in a very simple example the issue didn't show up. So in the end I just decided to extract the exact code that we use in our project as-is.)
With CMake 3.8.2 I get:
```
[tcsh][pcadp02]:build > ~/work/public/cmake/3.8.2/x86_64-slc6/bin/cmake ../PathSearchOrder/
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- 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: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using the LCG modules without setting up a release
-- Found CLHEP: /home/krasznaa/projects/searchOrder/PathSearchOrder/clhep1/include (found version "2.2.0.4")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/krasznaa/projects/searchOrder/build
```
While with 3.9.0:
```
[tcsh][pcadp02]:build > ~/work/public/cmake/3.9.0/x86_64-slc6/bin/cmake ../PathSearchOrder/
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- 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: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using the LCG modules without setting up a release
-- Found CLHEP: /home/krasznaa/projects/searchOrder/PathSearchOrder/clhep2/include (found version "2.2.0.4")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/krasznaa/projects/searchOrder/build
```
As you'll see, the main `CMakeLists.txt` file sets up the two paths with:
```cmake
# Set up the two CLHEP search paths in two different ways:
set( ENV{CMAKE_PREFIX_PATH} "${CMAKE_SOURCE_DIR}/clhep1" )
set( CLHEP_ROOT "${CMAKE_SOURCE_DIR}/clhep2" )
```
Our own `FindCLHEP.cmake` module is set up to respect the `CLHEP_ROOT` variable while searching for CLHEP. But our code was written to assume that `CMAKE_PREFIX_PATH` would be searched first. This is a **very** important assumption in our code.
Was this change in 3.9.0 intentional? I assume not, because with a configuration that sets `CMAKE_PREFIX_PATH` and `CLHEP_ROOT` in the same file that then calls `find_path`, the issue doesn't seem to show up. The difference is only visible in such a more complex setup.
This unfortunately makes all of our existing software releases unusable with CMake 3.9.0. So we'd very much like a resolution to this where we get the previous behaviour back. Otherwise we'll be in some serious trouble. :frowning:
Cheers,
Attila3.9.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17118VS: cmake 3.9.0 randomly errors out on Appveyor build machine with MSBuild.ex...2017-08-04T12:38:44-04:00Max HoraVS: cmake 3.9.0 randomly errors out on Appveyor build machine with MSBuild.exe failureRecently we have switched to cmake 3.9.0 and found random failures related to MSBuild.
Command line sample: cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
CMake output:
```
CMake Error at CMakeLists.txt:19 (project...Recently we have switched to cmake 3.9.0 and found random failures related to MSBuild.
Command line sample: cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
CMake output:
```
CMake Error at CMakeLists.txt:19 (project):
Failed to run MSBuild command:
C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 7/29/2017 12:38:16 AM.
The target "_ConvertPdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,37)" does not exist in the project, and will be ignored.
The target "_CollectPdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,70)" does not exist in the project, and will be ignored.
The target "_CollectMdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,38)" does not exist in the project, and will be ignored.
The target "_CopyMdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,71)" does not exist in the project, and will be ignored.
Project "C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj" on node 1 (default targets).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Release|x64. [C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj]
Done Building Project "C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj" (default target) (1) ->
(PrepareForBuild target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Release|x64. [C:\projects\arrow\cpp\build\CMakeFiles\3.9.0\VCTargetsPath.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.97
Exit code: 1
```
We have noticed that 3.9.0 version of cmake generates folder "3.9.0" and puts VCTargetsPath.vcxproj file into it.
Content of the `VCTargetsPath.vcxproj` on failure is following:
```
<?xml version="1.0" encoding="UTF-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{F3FC6D86-508D-3FB1-96D2-995F08B142EC}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
<Platform>x64</Platform>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props"/>
<PropertyGroup Label="Configuration">
<ConfigurationType>Utility</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<PlatformToolset>v140</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props"/>
<ItemDefinitionGroup>
<PostBuildEvent>
<Command>echo VCTargetsPath=$(VCTargetsPath)</Command>
</PostBuildEvent>
</ItemDefinitionGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets"/>
</Project>
```
Full content of CMake build directory during the failure is attached as [zip archive](/uploads/42747c0ddff0c4d88c0573960a2fba00/build.zip).
Link to AppVeyor job with failure: https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/build/1.0.2593/job/q484cyl1one8gn2l3.9.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17096cmake 3.9 for android is broken2017-08-04T09:11:45-04:00WangBincmake 3.9 for android is brokenhttps://github.com/android-ndk/ndk/issues/467
`-isystem /usr/include` is appended to compiler flags. clang will not prefix `SYSROOT` for those dirs, instead `-iwithsysroot /usr/include` should be used. gcc is a little different. Accordi...https://github.com/android-ndk/ndk/issues/467
`-isystem /usr/include` is appended to compiler flags. clang will not prefix `SYSROOT` for those dirs, instead `-iwithsysroot /usr/include` should be used. gcc is a little different. According the document https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
> Add the directory dir to the list of directories to be searched for header files during preprocessing. If dir begins with ‘=’ or $SYSROOT, then the ‘=’ or $SYSROOT is replaced by the sysroot prefix; see --sysroot and -isysroot.
, `-isystem=/usr/include` or `-isystem =/usr/include` should be used.3.9.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17091FindJava: OpenJDK 9 (Debian) version string not parsed2017-07-28T07:18:09-04:00Felix GeyerFindJava: OpenJDK 9 (Debian) version string not parsedFindJava is unable to parse the version of OpenJDK 9 from Debian (currently in the experimental suite).
Tested with cmake 3.9.0.
```
CMake Warning at /usr/share/cmake-3.9/Modules/FindJava.cmake:157 (message):
regex not supported: ope...FindJava is unable to parse the version of OpenJDK 9 from Debian (currently in the experimental suite).
Tested with cmake 3.9.0.
```
CMake Warning at /usr/share/cmake-3.9/Modules/FindJava.cmake:157 (message):
regex not supported: openjdk version "9-Debian"
OpenJDK Runtime Environment (build 9-Debian+0-9b177-3)
OpenJDK 64-Bit Server VM (build 9-Debian+0-9b177-3, mixed mode). Please
report
Call Stack (most recent call first):
CMakeLists.txt:1 (find_package)
-- Found Java: /usr/bin/java (found version "..")
```
Downstream report: https://bugs.debian.org/8683273.9.1Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/17253CMake incompatible with Android NDK r16 clang toolchain2017-10-05T07:13:55-04:00Daniel SeitherCMake incompatible with Android NDK r16 clang toolchainWhen trying to build an Android project with NDK r16 beta 1 and the clang toolchain, the toolchain's paths are broken. This is a regression from the current stable release NDK r15c. It works when using the default GCC toolchain (which is...When trying to build an Android project with NDK r16 beta 1 and the clang toolchain, the toolchain's paths are broken. This is a regression from the current stable release NDK r15c. It works when using the default GCC toolchain (which is deprecated in NDK and will be removed).
Here's a minimal example:
CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.9)
project(CMakeAndroidTest)
add_executable(cmake-android-test main.cpp)
```
main.cpp:
```c++
int main() {
return 0;
}
```
The following was run with CMake 3.9.1 on Linux x86_64 (Fedora 26).
NDK r15c, default GCC toolchain: works
```
$ ANDROID_NDK=/path/to/ndk-r15c cmake .. -DCMAKE_SYSTEM_NAME=Android
-- Android: Targeting API '26' with architecture 'arm', ABI 'armeabi', and processor 'armv5te'
-- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9'
[...]
-- Build files have been written to: [...]
```
NDK r15c, clang toolchain: works
```
$ ANDROID_NDK=/path/to/ndk-r15c cmake .. -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang
-- Android: Targeting API '26' with architecture 'arm', ABI 'armeabi', and processor 'armv5te'
-- Android: Selected Clang toolchain 'arm-linux-androideabi-clang' with GCC toolchain 'arm-linux-androideabi-4.9'
[...]
-- Build files have been written to: [...]
```
NDK r16 beta 1, default GCC toolchain: works
```
$ ANDROID_NDK=/path/to/ndk-r16-beta1 cmake .. -DCMAKE_SYSTEM_NAME=Android
-- Android: Targeting API '26' with architecture 'arm', ABI 'armeabi', and processor 'armv5te'
-- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9'
[...]
-- Build files have been written to: [...]
```
NDK r16 beta 1, clang toolchain: fails
```
$ ANDROID_NDK=/path/to/ndk-r16-beta1 cmake .. -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang
-- Android: Targeting API '26' with architecture 'arm', ABI 'armeabi', and processor 'armv5te'
-- Android: Selected Clang toolchain 'arm-linux-androideabi-clang' with GCC toolchain 'arm-linux-androideabi-4.9'
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_C_COMPILER:
/path/to/ndk-r16-beta1/toolchains//prebuilt/linux-x86_64/bin/clang
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
/path/to/ndk-r16-beta1/toolchains//prebuilt/linux-x86_64/bin/clang++
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
```
The correct path where clang and clang++ are located is `/path/to/ndk-r16-beta1/toolchains/llvm/prebuilt/linux-x86_64/bin`. Notice the missing `llvm` in the path used by CMake.3.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17252find_boost fails with error in iOS cross-compilation scenario2017-09-18T13:47:00-04:00Frank Deinzerfind_boost fails with error in iOS cross-compilation scenarioHi,
Using the current cmake 3.9.1 searching for boost in a iOS scenario breaks the makefile generation.
Running `cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../bin/osx/iOS.cmake -DIOS_PLATFORM=OS -G Xcode .. `
with the CMakeLists.txt
```
PR...Hi,
Using the current cmake 3.9.1 searching for boost in a iOS scenario breaks the makefile generation.
Running `cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../bin/osx/iOS.cmake -DIOS_PLATFORM=OS -G Xcode .. `
with the CMakeLists.txt
```
PROJECT(Pipeline)
cmake_minimum_required(VERSION 3.5)
set(BOOST_ROOT ${CMAKE_SOURCE_DIR}/../boost CACHE PATH "Boost root directory")
set(Boost_VERSION 106400)
find_package(Boost 1.64.0 COMPONENTS thread)
```
fails with
```
-- Could NOT find Threads (missing: Threads_FOUND)
CMake Error in /usr/local/Cellar/cmake/3.9.1/share/cmake/Modules/FindBoost.cmake:
cmake_policy PUSH without matching POP
Call Stack (most recent call first):
CMakeLists.txt:6 (find_package)
-- Configuring incomplete, errors occurred!
```
A cmake trace is attached.
The (complete) CMakeLists.txt that causes the problems used to work with earlier versions of cmake.
Frank[trace.txt](/uploads/5e37631e5dc645a9929616e2546b5273/trace.txt)3.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17243[REGRESSION] Cannot use SOURCES target property inside generator expression i...2017-09-06T10:50:52-04:00Maciej[REGRESSION] Cannot use SOURCES target property inside generator expression in add_libraryAttached project configures and compiles successfully on cmake 3.7.2, while it fails on cmake 3.8.2 and cmake 3.9.1[cmake_test.tar.gz](/uploads/8e87a2cc44c25b7d60fc8d9c159ffafe/cmake_test.tar.gz)Attached project configures and compiles successfully on cmake 3.7.2, while it fails on cmake 3.8.2 and cmake 3.9.1[cmake_test.tar.gz](/uploads/8e87a2cc44c25b7d60fc8d9c159ffafe/cmake_test.tar.gz)3.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17191CMake 3.9 Generates build.ninja failed on Non-Engish Windows2022-10-26T18:10:13-04:00Force.Charlie-ICMake 3.9 Generates build.ninja failed on Non-Engish WindowsStarting with CMake 3.9, cmake cannot generates `build.ninja` on Non-Engish Windows. When we use `chcp 65001` or change current console CodePage, cmake can generates `build.ninja`.
cmake 3.8.2 is success.
CMake log:
```
CMake Error at...Starting with CMake 3.9, cmake cannot generates `build.ninja` on Non-Engish Windows. When we use `chcp 65001` or change current console CodePage, cmake can generates `build.ninja`.
cmake 3.8.2 is success.
CMake log:
```
CMake Error at C:/Program Files/CMake/share/cmake-3.9/Modules/CMakeTestCXXCompiler.cmake:44 (message):
The C++ compiler "C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX64/x86/cl.exe" is
not able to compile a simple test program.
It fails with the following output:
Change Dir: D:/git/vcpkg/buildtrees/gflags/x86-windows-rel/CMakeFiles/CMakeTmp
Run Build
Command:"D:/git/vcpkg/downloads/tools/ninja/ninja-1.7.2/ninja.exe"
"cmTC_81c7a"
ninja: error: build.ninja:30: loading 'rules.ninja':
系统找不到指定的文件。
include rules.ninja
^ near here
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:94 (project)
```
This error info is `The system cannot find
the file specified`
Your can use chcp change console codepage to non-Engish Windows (cp936) test `cmake -GNinja`.
```powershell
Function ProcessExec {
param(
[string]$FilePath,
[string]$Arguments,
[string]$WorkingDirectory
)
$ProcessInfo = New-Object System.Diagnostics.ProcessStartInfo
$ProcessInfo.FileName = $FilePath
Write-Host "$FilePath $Arguments $PWD"
if ($WorkingDirectory.Length -eq 0) {
$ProcessInfo.WorkingDirectory = $PWD
}
else {
$ProcessInfo.WorkingDirectory = $WorkingDirectory
}
$ProcessInfo.Arguments = $Arguments
$ProcessInfo.UseShellExecute = $false ## use createprocess not shellexecute
$Process = New-Object System.Diagnostics.Process
$Process.StartInfo = $ProcessInfo
if ($Process.Start() -eq $false) {
return -1
}
$Process.WaitForExit()
return $Process.ExitCode
}
Function ClangNinjaGenerator{
param(
[String]$ClangExe,
[String]$BuildDir
)
$env:CC=$ClangExe
$env:CXX=$ClangExe
Write-Host "Build llvm, Use: CC=$env:CC CXX=$env:CXX"
Set-Workdir $BuildDir
$Arguments=Get-ClangArgument
$oe=[Console]::OutputEncoding
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 ### Ninja need UTF8
$exitcode = ProcessExec -FilePath "cmake.exe" -Arguments $Arguments
if ($exitcode -ne 0) {
Write-Error "CMake exit: $exitcode"
return 1
}
[Console]::OutputEncoding=$oe
$PN = & Parallel
$exitcode = ProcessExec -FilePath "ninja.exe" -Arguments "all -j $PN"
return $exitcode
}
```
This problem can be reproduced
https://github.com/Microsoft/vcpkg/issues/16603.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17184InstallRequiredSystemLibraries doesn't work with VS 15.32017-09-06T11:50:03-04:00karlissInstallRequiredSystemLibraries doesn't work with VS 15.3VS 15.3 changed the MSVC redistributable library locations:
> Visual C++ Redist file directories have been renamed to Microsoft.VC141.* to match versioning with the toolset (14.1x). In Visual Studio 2017 RTM, these directories were inc...VS 15.3 changed the MSVC redistributable library locations:
> Visual C++ Redist file directories have been renamed to Microsoft.VC141.* to match versioning with the toolset (14.1x). In Visual Studio 2017 RTM, these directories were incorrectly named Microsoft.VC150.*.
If I understood correctly CMake currently uses `${CMAKE_MSVC_ARCH}/Microsoft.VC${vs}0.CRT` where vs is 15 but path has been changed to MicrosoftVC141.CRT, older version of VS2017 used Microsoft.VC150.CRT. Creating a test case is slightly problematic as Microsoft doesn't provide an easy way of downgrading to older versions of VS2017 so I can't verify the old behavior.3.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17179XCodeGenerator: Generated iOS app crashes on launch2018-10-19T15:01:20-04:00Nitish SakhawalkarXCodeGenerator: Generated iOS app crashes on launchI identified that this PR, https://gitlab.kitware.com/cmake/cmake/merge_requests/682, breaks creating an ios app in the 3.9.0 release. The app is created successfully, but because the `NSPrincipalClass` is set to `NSApplication`, the bui...I identified that this PR, https://gitlab.kitware.com/cmake/cmake/merge_requests/682, breaks creating an ios app in the 3.9.0 release. The app is created successfully, but because the `NSPrincipalClass` is set to `NSApplication`, the built iOS.app crashes on startup. AFAIK, `NSApplication` is for macOS apps. This key was not specified earlier, so this wasn't a problem.
I can create and use a custom plist.in file, to resolve my case, but I think that the default one should work.
If this is agreed upon as a problem, I can work to fix it. Thanks!3.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17178Xcode generator no longer re-runs custom commands when dependencies are modified2017-08-25T11:05:07-04:00Matt StevensXcode generator no longer re-runs custom commands when dependencies are modifiedCMake 3.9 broke dependency analysis of custom commands in Xcode via !1054. By specifying outputs without any inputs the script phase is only executed if one of the outputs is missing or a clean build is performed.
If it's not too diffic...CMake 3.9 broke dependency analysis of custom commands in Xcode via !1054. By specifying outputs without any inputs the script phase is only executed if one of the outputs is missing or a clean build is performed.
If it's not too difficult to achieve this scenario likely warrants a test case.3.9.2Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/17172CMake 3.9.1 Erroneously Adds ZERO_CHECK and C++ Project Automatically as Asse...2018-10-28T02:48:47-04:00Don BiglerCMake 3.9.1 Erroneously Adds ZERO_CHECK and C++ Project Automatically as Assembly References in Mixed C++/C# BuildI have a project that builds both C# code (using new native C# support) and C++ wrapped to C# using SWIG. CMake 3.9.1 erroneously adds the ZERO_CHECK project and the C++ shared library build generated by SWIG as dependent reference assem...I have a project that builds both C# code (using new native C# support) and C++ wrapped to C# using SWIG. CMake 3.9.1 erroneously adds the ZERO_CHECK project and the C++ shared library build generated by SWIG as dependent reference assemblies automatically. This causes the C# build to fail since they are not valid reference assemblies. They should only be added if they are valid c# projects. This is new behavior as the problem does not occur in CMake 3.8.2.3.9.2Michael StürmerMichael Stürmerhttps://gitlab.kitware.com/cmake/cmake/-/issues/17168New AutoUIC generates files in a different place from CMake 3.82017-08-16T11:25:38-04:00Adriaan de GrootNew AutoUIC generates files in a different place from CMake 3.8Here's another really obscure change caused by the AutoUIC improvements; again I'm not sure this is worth fixing.
[cmake-autouic.tgz](/uploads/ecd2c0921393b00137233a74264be088/cmake-autouic.tgz)
The tarball extracts to cmake-autouic/ a...Here's another really obscure change caused by the AutoUIC improvements; again I'm not sure this is worth fixing.
[cmake-autouic.tgz](/uploads/ecd2c0921393b00137233a74264be088/cmake-autouic.tgz)
The tarball extracts to cmake-autouic/ and the CMakeLists.txt contains a little explanation. Both CMake 3.8 and 3.9 generate a build system, but the one generated by CMake 3.8 fails to build project2, and CMake 3.9 fails to build project3.
When auto-generating UI headers from `<foo>.ui`,
- CMake 3.8 generates `ui_<foo>.h` in $CMAKE_CURRENT_BINARY_DIR
- CMake 3.9 generates `ui_<foo>.h` in $CMAKE_CURRENT_BINARY_DIR and in <project>_autogen/include/ ; the latter with the full path to the UI file as it is `#include`d from C++ source
Consider normal use how you refer to the generated header, assuming you have done `include_directories($CMAKE_BINARY_DIR)`:
- In CMake 3.8, `#include "rel/path/to/current/bindir/ui_foo.h"` will find it, since the header is generated in the current binary dir, and autouic only looks at the last part of the path.
- In CMake 3.9, the same applies.
But now consider a UI file in a subdirectory, referred to via a relative path in CMake:
- CMake 3.8 still generates it in $CMAKE_CURRENT_BINARY_DIR
- CMake 3.9 does, too, but also in a slightly different path, because it includes the full path to the UI file
Now including the file from C++ works differently:
- In CMake 3.8 you must use the include to current bindir, since that is where the file is generated
- In CMake 3.9 the source UI lives in a subdirectory, so you must provide the full path (relative to the AutoUIC search path, at least) to the UI file, otherwise AutoUIC won't find it.
So depending on your CMake version, the C++ code must use different `#include` paths to refer to the UI headers -- one with the full relative path, the other with the relative path to the current (list) directory.
The example tarball demonstrates this more clearly, I hope.
Since this is another one of those weird edge cases where "don't do that then" might be a viable answer, this is probably something for the documentation, although for the life of me I don't know how to write this down (perhaps "overly convoluted autoUIC setups are known to fail when moving to newer CMake").3.9.2Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17124cmake --find-package mode broken on imported targets since CMake 3.9.02017-09-11T18:43:14-04:00Ben Boeckelcmake --find-package mode broken on imported targets since CMake 3.9.0EDIT: This was originally a feature request that was later incorrectly determined to be a report of a regression from 3.8 to 3.9. By the time the mistake was discovered too many updates and references to this issue had been made with th...EDIT: This was originally a feature request that was later incorrectly determined to be a report of a regression from 3.8 to 3.9. By the time the mistake was discovered too many updates and references to this issue had been made with that assumption, so we converted the issue to the actual regression that did exist. **The original feature request has been moved to #17236.**
Changes in !829 broke `cmake --find-package` mode for packages that define imported targets by dropping commands like `add_library`.
3.9.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17276Multiple MAP_IMPORTED_CONFIG_ values breaks Visual Studio projects2017-09-14T07:37:26-04:00Paweł BylicaMultiple MAP_IMPORTED_CONFIG_ values breaks Visual Studio projectsAfter upgrading to CMake 3.9, the subprojects built with ExternalProject_Add are failing with:
```
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(21,33): error MSB4115: The "HasTrailingSlash" function only...After upgrading to CMake 3.9, the subprojects built with ExternalProject_Add are failing with:
```
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(21,33): error MSB4115: The "HasTrailingSlash" function only accepts a scalar value, but its argument "$(IntDir)" evaluates to "x64\RelWithDebInfo;Release\" which is not a scalar
```
Full log: https://ci.appveyor.com/project/ethereum/cpp-ethereum/build/1.0.2543
Project: https://github.com/ethereum/cpp-ethereum
This affects CMake 3.9.0 and 3.9.1. We have not tried 3.9.2.3.9.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17205AUTOMOC in Visual Studio creates _autogen target instead of using PRE_BUILD2017-11-23T06:39:59-05:00Sebastian HoltermannAUTOMOC in Visual Studio creates _autogen target instead of using PRE_BUILDUsing the Visual Studio generator AUTOMOC always creates an ``*_autogen`` target instead of using ``PRE_BUILD``.
The behavior appeared in CMake 3.9.0Using the Visual Studio generator AUTOMOC always creates an ``*_autogen`` target instead of using ``PRE_BUILD``.
The behavior appeared in CMake 3.9.03.9.3Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17309FindBoost missing policy PUSH in 3.9.2 and 3.9.32017-10-04T07:48:31-04:00Pierluigi TaddeiFindBoost missing policy PUSH in 3.9.2 and 3.9.3Since commit https://gitlab.kitware.com/cmake/cmake/commit/eddbd62d0f7a1cbc6ae3eb1e6c79b955125502d4 by @craig.scott the FindBoost.cmake perform a policy(POP) if the library is already found.
There is not corresponding policy(PUSH) in th...Since commit https://gitlab.kitware.com/cmake/cmake/commit/eddbd62d0f7a1cbc6ae3eb1e6c79b955125502d4 by @craig.scott the FindBoost.cmake perform a policy(POP) if the library is already found.
There is not corresponding policy(PUSH) in the file and thus the following error appears if the library is searched again:
```
CMake Error in C:/Program Files/CMake/share/cmake-3.9/Modules/FindBoost.cmake:
cmake_policy POP without matching PUSH
```3.9.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17418Regression: CMAKE_AUTOMOC_MOC_OPTIONS seems to be appended to the compiler in...2017-11-01T08:11:20-04:00EoDRegression: CMAKE_AUTOMOC_MOC_OPTIONS seems to be appended to the compiler in CMake 3.9Currently CMake 3.9 combined with Qt 5.9 (and only this specific combination) cause compile errors in some projects, for example Apitrace or Telegram. It does work fine with previous version of CMake or previous versions of Qt.
It seems...Currently CMake 3.9 combined with Qt 5.9 (and only this specific combination) cause compile errors in some projects, for example Apitrace or Telegram. It does work fine with previous version of CMake or previous versions of Qt.
It seems that the variable ``CMAKE_AUTOMOC_MOC_OPTIONS`` is appended to the linker and hence causes issue:
* Gentoo issue: https://bugs.gentoo.org/634292
* Debian issue: https://bugs.debian.org/871158
* Apitrace upstream issue: https://github.com/apitrace/apitrace/issues/528
```
Generating MOC predefs moc_predefs.h
AutoMoc: Error: moc predefs generation command failed
AutoMoc: Command:
/usr/bin/c++ -dM -E -c /usr/share/cmake-3.9/Modules/CMakeCXXCompilerABI.cpp -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/build/gui -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/gui -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/build/gui/qapitrace_autogen/include -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/thirdparty/khronos -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/thirdparty/snappy -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/thirdparty/libbacktrace -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/thirdparty/gtest/include -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1/common -I/tmp/tmp.cU62V3fLK5/src/apitrace-7.1 -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I/usr/lib/qt/mkspecs/linux-g++ -I/usr/include/qt/QtWebKitWidgets -I/usr/include/qt/QtWebKit -I/usr/include/qt/QtNetwork -I/usr/include -DHAVE_BACKTRACE=1 -DHAVE_READPROC_H -DHAVE_X11 -DQT_CORE_LIB -DQT_FORCE_ASSERTS -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_WEBKITWIDGETS_LIB -DQT_WEBKIT_LIB -DQT_WIDGETS_LIB -D_GNU_SOURCE -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -nn
AutoMoc: Command output:
c++: error: unrecognized command line option ‘-nn’; did you mean ‘-Qn’?
```
The Parameter ``-nn`` is added as a moc-only option the following way: https://github.com/apitrace/apitrace/blob/65d2605/gui/CMakeLists.txt#L74
Is this a regression in CMake or Qt?3.9.5Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/17436CMake no longer excludes libgcc_eh from the implicit link libraries2018-04-16T11:57:20-04:00Marc AldorasiCMake no longer excludes libgcc_eh from the implicit link librariesCommit d59e3509850329096a7d6dfbc037d721b70034c9 removed `gcc.*` from the list of filtered implicit link libraries. This causes CMake to add `-lgcc_eh` to the linker flags when compiling a mixed C/C++ project on mingw, which means `libgc...Commit d59e3509850329096a7d6dfbc037d721b70034c9 removed `gcc.*` from the list of filtered implicit link libraries. This causes CMake to add `-lgcc_eh` to the linker flags when compiling a mixed C/C++ project on mingw, which means `libgcc_eh.a` is statically linked into every binary. This means that each dll has its own copy of exception handling and TLS code, which can cause problems (see https://public.kitware.com/pipermail/cmake/2017-August/066128.html for an example). In addition, the GCC developers recommend against having multiple copies of libgcc_eh at runtime (see https://gcc.gnu.org/ml/gcc/2012-03/msg00104.html).
As a workaround, adding `list(REMOVE_ITEM CMAKE_C_IMPLICIT_LINK_LIBRARIES gcc_eh)` will stop it from being implicitly linked.
`gcc_eh.*` should be added to the list of filtered implicit link libraries to fix this problem.3.9.6Christian PfeifferChristian Pfeifferhttps://gitlab.kitware.com/cmake/cmake/-/issues/17444CMake thinks mt.exe failed even though it succeeded2017-11-10T10:44:46-05:00Isuru FernandoCMake thinks mt.exe failed even though it succeededI get
```
MT: command "mt /nologo /manifest CMakeFiles\hello_world.dir/intermediate.manifest /out:CMakeFiles\hello_world.dir/embed.manifest /notify_update" failed (exit code 0x41020001) with the following output:
```
Exit code 0x4102000...I get
```
MT: command "mt /nologo /manifest CMakeFiles\hello_world.dir/intermediate.manifest /out:CMakeFiles\hello_world.dir/embed.manifest /notify_update" failed (exit code 0x41020001) with the following output:
```
Exit code 0x41020001 is a success code according to https://developercommunity.visualstudio.com/content/problem/138528/155-preview-tons-of-random-linker-errors-that-work.html and https://msdn.microsoft.com/en-us/library/windows/desktop/aa363651(v=vs.85).aspx3.10.0Brad KingBrad King