CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-05-04T16:23:56-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/163713.7 regression with NSight Tegra2017-05-04T16:23:56-04:00Lars Bishop3.7 regression with NSight TegraIn the CMake 3.6.2 release, the VSNSight test app is fully supported with the command lines:
```
cmake.exe" -G"Visual Studio 14 2015" -DCMAKE_SYSTEM_NAME=Android ..
```
and
```
cmake.exe" -G"Visual Studio 12 2013" -DCMAKE_SYS...In the CMake 3.6.2 release, the VSNSight test app is fully supported with the command lines:
```
cmake.exe" -G"Visual Studio 14 2015" -DCMAKE_SYSTEM_NAME=Android ..
```
and
```
cmake.exe" -G"Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=Android ..
```
However, in CMake 3.7.20161012-g8eb60, the same test command lines fail in the "trycompile" stage, as they place tags
`<AndroidArch>arm</AndroidArch>`
in the test-compile VCXPROJ file instead of
`<AndroidArch>armv7-a</AndroidArch>`
This leads to
```
-- Check for working C compiler: C:/NVPACK/android-ndk-r12b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe -- broken
CMake Error at C:/tools/CMake/Modules/CMakeTestCCompiler.cmake:51 (message):
The C compiler
"C:/NVPACK/android-ndk-r12b/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe"
is not able to compile a simple test program.
```
Modifications to CMake that cause the `<AndroidArch>` value to be `armv7-a` appear to fix this. However, no combination of setting the various ANDROID-related CMake tags on the command line or config files seem to be able to do this. Also, the Test case driver in the 3.7 source tree does not seem to ad any such arguments.
I have attempted a few WARs in Android-Determine.cmake and have been able to make 3.7 work, but it is unclear whether these are correct at a higher level.
I am using NVIDIA CodeWorks for Android 1r5 with NDK r12b and NSightTegra 3.4.162313.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16366FindwxWidgets no longer finds MSVC library folders without version prefixes2017-05-04T16:23:56-04:00Raul Tambreraul@tambre.eeFindwxWidgets no longer finds MSVC library folders without version prefixesCMake 3.7 will no longer search for wxWidgets library folders on MSVC that don't have a version prefix. This is caused by [this commit](https://github.com/Kitware/CMake/commit/20d7da5276704864569fb08259278a08c5f9e725).
While official ...CMake 3.7 will no longer search for wxWidgets library folders on MSVC that don't have a version prefix. This is caused by [this commit](https://github.com/Kitware/CMake/commit/20d7da5276704864569fb08259278a08c5f9e725).
While official releases follow the convention by adding compiler version prefix, when you build manually wxWidgets yourself using MSVC, it will not append the compiler version. The compiler version [is added only for official builds](https://github.com/wxWidgets/wxWidgets/blob/master/docs/changes_30.txt#L526). A library folder named `vc_x64_lib` is generated instead. This **breaks** search for self-built MSVC wxWidgets libraries.
**Workaround:**
Name your library folder to include a version prefix of the MSVC compiler. (ie. `vc140_x64_lib`)3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16363Ninja generator does not emit POST_BUILD commands for Apple Framework targets2017-05-04T16:23:56-04:00Chris BNinja generator does not emit POST_BUILD commands for Apple Framework targetsI'm using CMake 3.6.2, so the file and line numbers referenced below are based on that.
I'm trying to add the following code change to LLDB to enable the LLDB framework to have an appropriate "Headers" directory in the build directory...I'm using CMake 3.6.2, so the file and line numbers referenced below are based on that.
I'm trying to add the following code change to LLDB to enable the LLDB framework to have an appropriate "Headers" directory in the build directory:
```cmake
add_custom_command(TARGET liblldb POST_BUILD COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_SOURCE_DIR}/include/lldb/API $<TARGET_FILE_DIR:liblldb>/Headers)
```
When using the Ninja generator this does not produce any errors, nor does it actually result in a command being added. Looking through the CMake sources this seems to be because in Framework targets `targetOutput` is not equal to `targetOutputReal`, so at [cmNormalNinjaTargetGenerator.cxx:604](https://gitlab.kitware.com/cmake/cmake/blob/v3.6.2/Source/cmNinjaNormalTargetGenerator.cxx#L604) the else block is taken which populates the `POST_BUILD` step on `symlinkVars`. Further down in the file at [cmNormalNinjaTargetGenerator.cxx:646](https://gitlab.kitware.com/cmake/cmake/blob/v3.6.2/Source/cmNinjaNormalTargetGenerator.cxx#L646), because the target is a framework the handling of `symlinkVars` gets skipped (which actually seems correct). I think the fix is to add `|| gt.IsFrameworkOnApple()` to [cmNormalNinjaTargetGenerator.cxx:604](https://gitlab.kitware.com/cmake/cmake/blob/v3.6.2/Source/cmNinjaNormalTargetGenerator.cxx#L604).
Thanks!
-Chris3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16359cmake-gui sublime text 2 ninja generator is broken2017-05-04T16:23:56-04:00Bruno Pedrosacmake-gui sublime text 2 ninja generator is brokenToday I was trying to generate a "Sublime Text 2 - Ninja" configuration using cmake-gui and output wasn't any [.sublime-project](http://screencast.com/t/9TzCEPYL) but a [vs2015 solution](http://screencast.com/t/vPPbGpKhITUR). The generat...Today I was trying to generate a "Sublime Text 2 - Ninja" configuration using cmake-gui and output wasn't any [.sublime-project](http://screencast.com/t/9TzCEPYL) but a [vs2015 solution](http://screencast.com/t/vPPbGpKhITUR). The generators listed by cmake-gui are these [ones](http://screencast.com/t/KVmutS2z), they are strings like "*- Sublime Text 2".
cmake-gui output looked kinda broken to me so after that I've tried using directly `cmake .. -G "Sublime Text 2 - Ninja` and the output was just [fine](http://screencast.com/t/9u7ZNGgI), it seems like cmake-gui is kinda broken, generators should match exactly cmake ones and the output should be correct.
From my newbie perspective, I'd say that "CMake Error: SetGlobalGenerator called with null" says quite a lot about it. Maybe the string is just wrong and it's not able to index properly on the available generators3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16355Some cross compiling macOS -> iOS cases broken since CMake 3.42017-06-19T12:45:23-04:00MemphizSome cross compiling macOS -> iOS cases broken since CMake 3.4Commit 24aafbde115647b7e599d112d0bcc4f03c3e9b88 broke cross compilation for ios / tvos.
Before this it was possible to not set CMAKE_OSX_DEPLOYMENT_TARGET which is ok when you do cross compile and pass sysroot and deployment-target vi...Commit 24aafbde115647b7e599d112d0bcc4f03c3e9b88 broke cross compilation for ios / tvos.
Before this it was possible to not set CMAKE_OSX_DEPLOYMENT_TARGET which is ok when you do cross compile and pass sysroot and deployment-target via cflags, cxxflags.
WIth this commit the CMAKE_OSX_DEPLOYMENT_TARGET is set to the version of the host os in some situations. This results in the fact that the -mmacosx-version-min= flag is added to cflags / cxxflags.
When compiling for ios for example in need to set -miphoneos-version-min instead ... with this change - both gets set ( "-miphoneos-version-min" <- through my toolchain.cmake and "-mmacosx-version-min" because of CMAKE_OSX_DEPLOYMENT_TARGET) and cmake fails during compiler checking because this is an invalid combination of flags.
Might be the cause for this too: #16349 - not sure. (EDIT: it is not)3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/163523.7.0-rc1 breaks some Visual Studio 2015 project files using /std:c++latest2017-05-04T16:23:56-04:00David Hunter3.7.0-rc1 breaks some Visual Studio 2015 project files using /std:c++latestVS 2015 introduced a /std flag to indicate what flavor of C++ you want for instance /std:c++latest. This hadn't really been built into MSBuild XML so appeared
in the <AddidtionalOptions> MSBuild element with CMake 3.6. With VS 15 and MS...VS 2015 introduced a /std flag to indicate what flavor of C++ you want for instance /std:c++latest. This hadn't really been built into MSBuild XML so appeared
in the <AddidtionalOptions> MSBuild element with CMake 3.6. With VS 15 and MSBuild 15.0 there is now an MSBuild element
<LanguageStandard>stdcpplatest</LanguageStandard>
which CMake 3.7.0-rc1 correctly uses.
However when generating for VS 2015 CMake now also uses the <LanguageStandard> element which VS 2015/MSBuild 14.0 does not recognize and ignores. This breaks builds that needed /std:c++latest behaviour.
As far as I can tell there is no way in CMake to directly add text to <AddidtionalOptions> so there is no work around I can find.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16350Android: Add support for `cxxabi.h`2017-05-04T16:23:56-04:00Brad KingAndroid: Add support for `cxxabi.h`For some values of [CMAKE_ANDROID_STL_TYPE](https://cmake.org/cmake/help/v3.7/variable/CMAKE_ANDROID_STL_TYPE.html) the `cxxabi.h` header requires additional include directories.For some values of [CMAKE_ANDROID_STL_TYPE](https://cmake.org/cmake/help/v3.7/variable/CMAKE_ANDROID_STL_TYPE.html) the `cxxabi.h` header requires additional include directories.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16346cmake 3.7.0-rc1 can't configure with c++_static project using Android NDK r1...2017-05-04T16:24:37-04:00David Netocmake 3.7.0-rc1 can't configure with c++_static project using Android NDK r13 release candidateI can't configure a project with cmake 3.7.0-rc1 using CMAKE_ANDROID_STL_TYPE=c++_static
The NDK has rearranged its libc++ sources since r12b.
You can find the NDK r13 release candidates at https://partner.android.com/build?pli=1#p:id...I can't configure a project with cmake 3.7.0-rc1 using CMAKE_ANDROID_STL_TYPE=c++_static
The NDK has rearranged its libc++ sources since r12b.
You can find the NDK r13 release candidates at https://partner.android.com/build?pli=1#p:id=buildlist&a=100621237&h=YnJhbmNoPWFvc3AtbmRrLXIxMy1yZWxlYXNlJnByb2R1Y3Q9bGludXg
I used Android NDK r13 build 3316327
Example:
```
cmake -G Ninja -DCMAKE_SYSTEM_NAME=Android \
-DCMAKE_ANDROID_ARCH_ABI=arm64-v8a \
-DCMAKE_ANDROID_NDK=$HOME/android-ndk-r13 \
-DCMAKE_ANDROID_STL_TYPE=c++_static \
../SPIRV-Headers
```
I get this result:
```
-- Android: Targeting API '24' with architecture 'arm64', ABI 'arm64-v8a', and processor 'aarch64'
-- Android: Selected GCC toolchain 'aarch64-linux-android-4.9'
-- The C compiler identification is GNU 4.9.0
-- The CXX compiler identification is GNU 4.9.0
-- Check for working C compiler: /local/android-ndk-r13/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-gcc
-- Check for working C compiler: /local/android-ndk-r13/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at /local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/Platform/Android-Common.cmake:54 (message):
Android: STL 'c++_static' include directory not found:
/local/android-ndk-r13/sources/cxx-stl/llvm-libc++/libcxx/include
Call Stack (most recent call first):
/local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/Platform/Android/ndk-stl-c++.cmake:6 (__android_stl_inc)
/local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/Platform/Android/ndk-stl-c++_static.cmake:3 (__android_stl_cxx)
/local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/Platform/Android-Common.cmake:146 (__android_stl)
/local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/Platform/Android-GNU.cmake:32 (__android_compiler_common)
/local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/Platform/Android-GNU-CXX.cmake:2 (__android_compiler_gnu)
/local/cmake-3.7.0-rc1/share/cmake-3.7/Modules/CMakeCXXInformation.cmake:48 (include)
CMakeLists.txt:32 (project)
-- Configuring incomplete, errors occurred!
```
I think the problem shows up when configuring any project. I used https://github.com/KhronosGroup/SPIRV-Headers in my test case because it's small and simple.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16333cmake-3.6.2-win64-x64.msi: HTML help missing2018-02-20T16:28:55-05:00Hendrik Sattlercmake-3.6.2-win64-x64.msi: HTML help missingIn the cmake-3.6.2-win64-x64.msi, the HTML help is missing but it is present in cmake-3.6.2-win32-x86.msiIn the cmake-3.6.2-win64-x64.msi, the HTML help is missing but it is present in cmake-3.6.2-win32-x86.msi3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16332ninja generator fortran support: original source file directory is not search...2018-02-20T16:28:55-05:00Keith Millerninja generator fortran support: original source file directory is not searched when using fortran INCLUDE statementWhen a file is INCLUDEed in fortran, the original source directory that contains the source file with the INCLUDE statement should be searched for the included file ahead of any directories that are specified with -I. It would normally ...When a file is INCLUDEed in fortran, the original source directory that contains the source file with the INCLUDE statement should be searched for the included file ahead of any directories that are specified with -I. It would normally be functionality that is implicitly provided by the compiler, but since the pre-processed file is located out-of-tree, the original source directory may need to be added to the include path?
Please find attached test case:
[ftest.tar.xz](/uploads/ef25355d9e5bc684b7d335fe27527112/ftest.tar.xz)3.7.0Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/16331FindCxxTest runs incorrect python executable2018-02-20T16:28:55-05:00Orion PoplawskiFindCxxTest runs incorrect python executableOn Fedora 24+, cxxtestgen is a python3 executable with a #!/usr/bin/python3 shbang. However, FindCxxTest calls it with /usr/bin/python, which fails. See http://public.kitware.com/pipermail/cmake/2016-August/064027.html for more.
There...On Fedora 24+, cxxtestgen is a python3 executable with a #!/usr/bin/python3 shbang. However, FindCxxTest calls it with /usr/bin/python, which fails. See http://public.kitware.com/pipermail/cmake/2016-August/064027.html for more.
There is no need to call with python explicitly on Linux/Unix. Not sure what the situation on Windows is.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16330project(... LANGUAGES C CXX RC) causes "Recursive call not allowed"2018-02-01T18:14:37-05:00Kevin Puetzproject(... LANGUAGES C CXX RC) causes "Recursive call not allowed"After upgrading from CMake 3.5.2 to 3.6.2, we are now experiencing an error
```
-- The C compiler identification is MSVC 19.0.23918.0
CMake Error at cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/Platform/Windows-MSVC.cmake:326 (enab...After upgrading from CMake 3.5.2 to 3.6.2, we are now experiencing an error
```
-- The C compiler identification is MSVC 19.0.23918.0
CMake Error at cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/Platform/Windows-MSVC.cmake:326 (enable_language):
Language 'RC' is currently being enabled. Recursive call not allowed.
Call Stack (most recent call first):
cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/Platform/Windows-MSVC-C.cmake:5 (__windows_compiler_msvc)
cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/CMakeCInformation.cmake:58 (include)
CMakeLists.txt:2 (project)
```
This appears even in a minimized sample project
```
project(foo LANGUAGES C CXX RC)
```
I have reproduced it as far back as 3.6.0-rc1; in 3.5.2 and earlier, our project works fine.
My guess from skimming the history is that this regression begins after #15999/72e0dc58d3caf63a57975e97ce13c5dc4b38cf9b, though I haven't recompiled CMake to prove it.
I am not using any custom toolchain; the error seems to be independent of Generator, but the exact messages above are from the default "Visual Studio 14 2015". From the backtrace, it appears the Platform/Windows-MSVC.cmake is at fault.
Our project is explicitly enabling the RC language because we are also building for with g++ and winelib. On that platform we *do* use a toolchain file, which sets up wrc as the RC_COMPILER. But it does not enable_language, we let the projects that use .rc files do it.
```
SET(CMAKE_RC_COMPILER "${WINE_WRC}")
SET(CMAKE_RC_OUTPUT_EXTENSION .res)
SET(CMAKE_RC_SOURCE_FILE_EXTENSIONS .rc)
```3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16326With Xcode 8 CMake cannot detect Swift compiler2017-06-27T14:59:10-04:00Gregor JasnyWith Xcode 8 CMake cannot detect Swift compilerI get the following error:
```
Compiling the Swift compiler identification source file "CompilerId/main.swift" failed.
Compiler:
Build flags:
Id flags:
The output was:
65
=== BUILD TARGET CompilerIdSwift OF PROJECT Compil...I get the following error:
```
Compiling the Swift compiler identification source file "CompilerId/main.swift" failed.
Compiler:
Build flags:
Id flags:
The output was:
65
=== BUILD TARGET CompilerIdSwift OF PROJECT CompilerIdSwift WITH THE DEFAULT CONFIGURATION (Debug) ===
Check dependencies
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.
** BUILD FAILED **
```
The trick is to specify the required Swift version in the Xcode project:
```
isa = XCBuildConfiguration;
buildSettings = {
PRODUCT_NAME = CompilerIdSwift;
+ SWIFT_VERSION = 2.3;
};
```3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16325Deriving CMAKE_OSX_SYSROOT from CMAKE_OSX_DEPLOYMENT_TARGET is not correct2018-02-20T16:28:56-05:00Nat!Deriving CMAKE_OSX_SYSROOT from CMAKE_OSX_DEPLOYMENT_TARGET is not correctThe problem is that `CMAKE_OSX_SYSROOT` says
```
If not set explicitly the value is initialized by the SDKROOT environment variable, if set, and otherwise computed based on the CMAKE_OSX_DEPLOYMENT_TARGET or the host platform.
```
...The problem is that `CMAKE_OSX_SYSROOT` says
```
If not set explicitly the value is initialized by the SDKROOT environment variable, if set, and otherwise computed based on the CMAKE_OSX_DEPLOYMENT_TARGET or the host platform.
```
The purpose of `CMAKE_OSX_DEPLOYMENT_TARGET` is to set the *minimum* OS X version on which the product should run. `CMAKE_OSX_SYSROOT` should not concern itself with `CMAKE_OSX_DEPLOYMENT_TARGET` at all.
Here is an example to illustrate:
Let's say I write a project on 10.12. I want it to stay compatible for 10.12, even if 10.13/14/15... comes out and I compile it with the newer OS X/Xcode.
I therefore set the `CMAKE_OSX_DEPLOYMENT_TARGET` to 10.12. What I do not want, is to manually set `CMAKE_OSX_SYSROOT` everytime a new OS X version comes out. It's not neccessary.
If I don't set `CMAKE_OSX_SYSROOT` manually, then in newer OS X versions the SDK might not be present for 10.12 and cmake fails! But the presence of the 10.12 SDK is **not** needed to use the `-mmacosx-version-min` option generated by `CMAKE_OSX_DEPLOYMENT_TARGET`.3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16323Cannot detect Xcode SDK version from unversioned SDK path2017-06-27T14:59:10-04:00Gregor JasnyCannot detect Xcode SDK version from unversioned SDK pathStaring with Xcode 8 the SDK path might be unversioned, too. The following should work properly:
```
cmake -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -DCMAKE_OSX...Staring with Xcode 8 the SDK path might be unversioned, too. The following should work properly:
```
cmake -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -DCMAKE_OSX_DEPLOYMENT_TARGET=10.10 -GXcode ..
```
See discussion in: http://public.kitware.com/pipermail/cmake/2016-September/064263.html3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16320FindOpenSSL fails to find release libraries with MD or MT suffix from slprowe...2018-12-07T09:57:12-05:00dummyunitFindOpenSSL fails to find release libraries with MD or MT suffix from slproweb distributionOn Windows with openssl from [slproweb.com](https://slproweb.com/products/Win32OpenSSL.html) installed and when MSVC generator is used FindOpenSSL module always finds lib/ssleay32.lib and lib/libeay32.lib as a release libraries instead o...On Windows with openssl from [slproweb.com](https://slproweb.com/products/Win32OpenSSL.html) installed and when MSVC generator is used FindOpenSSL module always finds lib/ssleay32.lib and lib/libeay32.lib as a release libraries instead of libraries with MT or MD suffix from lib/VC/ folder.
Setting OPENSSL_USE_STATIC_LIBS and OPENSSL_MSVC_STATIC_RT affects only which debug library will be found.
This problem was introduced in commit b148440381df0143a665b7ceebe8606a052e2cdf which fixed issue #15887, if a manually revert this commit problem goes away.
Sample CMakeLists.txt to demonstrate the problem:
```
cmake_minimum_required(VERSION 3.6)
project(foo)
set(OPENSSL_MSVC_STATIC_RT true)
set(OPENSSL_USE_STATIC_LIBS true)
find_package(OpenSSL)
message(STATUS "${OPENSSL_LIBRARIES}")
```
This prints:
```
optimized;D:/OpenSSL-Win32/lib/ssleay32.lib;debug;D:/OpenSSL-Win32/lib/VC/static/ssleay32MTd.lib;optimized;D:/OpenSSL-Win32/lib/libeay32.lib;debug;D:/OpenSSL-Win32/lib/VC/static/libeay32MTd.lib
```
while correct OPENSSL_LIBRARIES value should be:
```
optimized;D:/OpenSSL-Win32/lib/VC/static/ssleay32MT.lib;debug;D:/OpenSSL-Win32/lib/VC/static/ssleay32MTd.lib;optimized;D:/OpenSSL-Win32/lib/VC/static/libeay32MT.lib;debug;D:/OpenSSL-Win32/lib/VC/static/libeay32MTd.lib
```3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16319CMake 3.6.2 XCODE_ATTRIBUTE_DEPLOYMENT_LOCATION does not work2022-09-26T10:47:20-04:00robinCMake 3.6.2 XCODE_ATTRIBUTE_DEPLOYMENT_LOCATION does not workset XCODE_ATTRIBUTE_DEPLOYMENT_LOCATION YES for target does not work in cmake 3.6.2. It used to work in cmake 3.4.3set XCODE_ATTRIBUTE_DEPLOYMENT_LOCATION YES for target does not work in cmake 3.6.2. It used to work in cmake 3.4.33.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16295file(LOCK ... RELEASE) does not work on win322018-02-20T16:28:55-05:00Egor Puginfile(LOCK ... RELEASE) does not work on win32Hi,
On win32 `file(LOCK ... RELEASE)` might fail in some cases.
I debugged the issue - `cmFileLock::Release()` is not called at all.
The issue is that
```
bool cmFileLock::IsLocked(const std::string& filename) const
{
return...Hi,
On win32 `file(LOCK ... RELEASE)` might fail in some cases.
I debugged the issue - `cmFileLock::Release()` is not called at all.
The issue is that
```
bool cmFileLock::IsLocked(const std::string& filename) const
{
return filename == this->Filename;
}
```
from `Source/cmFileLock.cxx:61` returns `false`.
In my case the difference is in the first letter.
```
this->Filename == "g:/dev/cppan_storage/cfg/amd64-msvc-19.0-32.cmake.lock"
filename == "G:/dev/cppan_storage/cfg/amd64-msvc-19.0-32.cmake.lock"
```
`g` becomes `G` in file `Source/cmFileCommand.cxx:3115`.
```
// Unify path (remove '//', '/../', ...)
path = cmSystemTools::CollapseFullPath(path);
```
This is actually a sad error. Did you consider something like `boost::filesystem::path` (maybe future `std::filesystem::path`)?3.7.0Ruslan Baratovx@ruslo.devRuslan Baratovx@ruslo.devhttps://gitlab.kitware.com/cmake/cmake/-/issues/16294"/Zc:inline" and "/Zc:rvalueCast" MSVC compiler flags don't set in VS14 file ...2018-02-20T16:28:55-05:00invexed"/Zc:inline" and "/Zc:rvalueCast" MSVC compiler flags don't set in VS14 file generation`<RemoveUnreferencedCodeData>true</RemoveUnreferencedCodeData>
<EnforceTypeConversionRules>true</EnforceTypeConversionRules>
`
missing from generated project file(s).`<RemoveUnreferencedCodeData>true</RemoveUnreferencedCodeData>
<EnforceTypeConversionRules>true</EnforceTypeConversionRules>
`
missing from generated project file(s).3.7.0https://gitlab.kitware.com/cmake/cmake/-/issues/16293build rpath does not prevent picking up installed library when using PKG_CHEC...2018-02-20T16:28:55-05:00Dan Kegelbuild rpath does not prevent picking up installed library when using PKG_CHECK_MODULESOn Linux, cmake very nicely switches between build time rpath and installed rpath.
And it has PKG_CHECK_MODULES which lets you use libraries installed with .pc files.
So far so good.
But if one of the libraries you use via PKG_CHECK_MOD...On Linux, cmake very nicely switches between build time rpath and installed rpath.
And it has PKG_CHECK_MODULES which lets you use libraries installed with .pc files.
So far so good.
But if one of the libraries you use via PKG_CHECK_MODULES specifies an rpath,
and the library you're developing gets installed to the same place as one of those libraries,
you can end up with mysterious crashes.
Changing cmLocalGenerator::OutputLinkLibraries() to add the build rpath entries *before* the ones from CFLAGS resolves the problem.3.7.0Brad KingBrad King