CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-05-04T16:23:55-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16394-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken i...2017-05-04T16:23:55-04:00jwhowarth-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in cmake 3.7.0-rc2While building the new gromacs 2016 release against the LLVM.org clang 3.9.0 compilers, in order to use its openmp support, I discovered that cmake 3.7.0-rc2 no longer honors the expected behavior for -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING...While building the new gromacs 2016 release against the LLVM.org clang 3.9.0 compilers, in order to use its openmp support, I discovered that cmake 3.7.0-rc2 no longer honors the expected behavior for -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/.
Specially the gromacs build fails in...
```
CMAKE_OPTIONS="-DGMX_FFT_LIBRARY=fftw3 \
-DGMX_GPU="OFF" \
-DGMX_X11="ON" \
-DCMAKE_INSTALL_NAME_DIR=/sw/lib \
-DCMAKE_INSTALL_PREFIX=/sw \
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \
-DCMAKE_OSX_SYSROOT:STRING=/"
if [ -f /sw/src/fink.build/gromacs-2016-1/gromacs-2016/INSTALL_MAKE_CHECK ]; then
CMAKE_OPTIONS="$CMAKE_OPTIONS -DREGRESSIONTEST_PATH=/sw/src/fink.build/gromacs-2016-1/gromacs-2016/regressiontests-2016"
fi
# no assembler support for AVX intrinsics until transition to clang
if [ "x86_64" == "x86_64" -o "x86_64" == "i386" ]; then
CMAKE_OPTIONS="$CMAKE_OPTIONS -DGMX_SIMD:STRING=SSE2"
fi
# first build/test/install standard library
cmake $CMAKE_OPTIONS ..
-- The C compiler identification is Clang 3.9.0
-- The CXX compiler identification is Clang 3.9.0
-- Check for working C compiler: /sw/bin/clang-3.9
-- Check for working C compiler: /sw/bin/clang-3.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /sw/bin/clang++-3.9
-- Check for working CXX compiler: /sw/bin/clang++-3.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test CXXFLAG_STD_CXX0X
-- Performing Test CXXFLAG_STD_CXX0X - Success
-- Performing Test CXX11_SUPPORTED
-- Performing Test CXX11_SUPPORTED - Success
-- Performing Test CXX11_STDLIB_PRESENT
-- Performing Test CXX11_STDLIB_PRESENT - Failed
CMake Error at cmake/gmxTestCXX11.cmake:138 (message):
This version of GROMACS requires C++11-compatible standard library. Please
use a newer compiler, or a newer standard library, or use the GROMACS 5.1.x
release. See the installation guide for details.
Call Stack (most recent call first):
CMakeLists.txt:164 (gmx_test_cxx11)
[CMakeError.log](/uploads/292cc44c089697527d7bf9eb8e253dce/CMakeError.log)
```
This issue doesn't occur under cmake 3.6.2.3.7.0Gregor JasnyGregor Jasnyhttps://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/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/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/16218ExternalProject.cmake and macOS .DS_store2018-02-20T16:28:55-05:00Patrice KouameExternalProject.cmake and macOS .DS_storeDuring the extraction phase in _ep_write_extractfile_script, a .DS_Store file is sometimes created in the temporary download directory. Unfortunately, this misleads the logic intended to move the extracted contents to the destination dir...During the extraction phase in _ep_write_extractfile_script, a .DS_Store file is sometimes created in the temporary download directory. Unfortunately, this misleads the logic intended to move the extracted contents to the destination directory and adds another unnecessary (and deal breaking) sub-directory. For example:
Expected result :
- ../ext_target_prefix/src/ext_target/exploded_tarfile_directory_contents.
Actual Result:
- ../ext_target_prefix/src/ext_target/exploded_tarfile_directory/exploded_tarfile_directory_contents.
Because of this state before the move:
- ../ext_target_prefix/src/ext_target1234/.
- ../ext_target_prefix/src/ext_target1234/.DS_Store <---- Offending .DS_Store file.
- ../ext_target_prefix/src/ext_target1234/exploded_tarfile_directory/exploded_tarfile_directory_contents.
The following code within the function moves the contents of the exploded directory or the directory itself depending on a count of files:
```cmake
# Analyze what came out of the tar file:
#
message(STATUS \"extracting... [analysis]\")
file(GLOB contents \"\${ut_dir}/*\")
list(LENGTH contents n)
if(NOT n EQUAL 1 OR NOT IS_DIRECTORY \"\${contents}\")
set(contents \"\${ut_dir}\")
endif()
# Move \"the one\" directory to the final directory:
#
message(STATUS \"extracting... [rename]\")
file(REMOVE_RECURSE \${directory})
get_filename_component(contents \${contents} ABSOLUTE)
file(RENAME \${contents} \${directory})
```
In most cases (if not all?) cmake should ignore the .DS_Store Mac specific folder attribute files. I fixed this myself by removing the the .DS_Store entry from the list like so:
```cmake
# Analyze what came out of the tar file:
#
message(STATUS \"extracting... [analysis]\")
file(GLOB contents \"\${ut_dir}/*\")
list(REMOVE_ITEM contents \"\${ut_dir}/.DS_Store\")
list(LENGTH contents n)
if(NOT n EQUAL 1 OR NOT IS_DIRECTORY \"\${contents}\")
set(contents \"\${ut_dir}\")
endif()
# Move \"the one\" directory to the final directory:
#
message(STATUS \"extracting... [rename]\")
file(REMOVE_RECURSE \${directory})
get_filename_component(contents \${contents} ABSOLUTE)
file(RENAME \${contents} \${directory})
```
I attempted to control the OS X tar extraction behavior to exclude these pesky annoyances or even some obscure environment variables that Google up, to no avail. Haven't found any consistent documented logic behind when tar creates these or not as I have another source code .tar.gz that explodes just fine. Maybe just me, but in general cmake logic needs to take into account the "possible" existence of these Mac artifacts.
3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16158install_name_dir is ignored2017-06-27T14:59:10-04:00Volker Dauminstall_name_dir is ignoredIn cmake-3.5.2 the variable CMAKE_INSTALL_NAME_DIR (necessary for RPATH settings in OSX)gets ignored in some cases because of a wrong check. The according diff is attached.
[install_name_dir.diff](/uploads/68a4c6c63b5409468a277f71c8e1...In cmake-3.5.2 the variable CMAKE_INSTALL_NAME_DIR (necessary for RPATH settings in OSX)gets ignored in some cases because of a wrong check. The according diff is attached.
[install_name_dir.diff](/uploads/68a4c6c63b5409468a277f71c8e1da98/install_name_dir.diff) 3.7.0Clinton StimpsonClinton Stimpsonhttps://gitlab.kitware.com/cmake/cmake/-/issues/16148Allow BUNDLE_EXTENSION for MACOSX_BUNDLE executables2018-02-20T16:28:55-05:00Kevin WojniakAllow BUNDLE_EXTENSION for MACOSX_BUNDLE executablesBUNDLE_EXTENSION currently only applies to MODULE libraries which have BUNDLE set to true. However, sometimes it is needed to change an application bundle's extension. One example is an [XPC Service](https://developer.apple.com/library/m...BUNDLE_EXTENSION currently only applies to MODULE libraries which have BUNDLE set to true. However, sometimes it is needed to change an application bundle's extension. One example is an [XPC Service](https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html) which are bundles, but they contain a main() and run as processes, so using the add_library/MODULE/BUNDLE combination does not make sense in this context.3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16147BUNDLE_EXTENSION doesn't apply for Xcode generator2017-06-27T14:59:10-04:00Kevin WojniakBUNDLE_EXTENSION doesn't apply for Xcode generatorWhen BUNDLE_EXTENSION is used with the Xcode generator, the extension does not change and stays as "bundle". When Unix Makefiles generator is used, the extension changes as expected.
Here is a sample project which reproduces the issue...When BUNDLE_EXTENSION is used with the Xcode generator, the extension does not change and stays as "bundle". When Unix Makefiles generator is used, the extension changes as expected.
Here is a sample project which reproduces the issue (using CMake 3.5.2 from homebrew, and Xcode 7.3.1):
cmake_minimum_required(VERSION 3.5)
project(mytest)
add_library(mytest MODULE main.c)
set_target_properties(mytest PROPERTIES BUNDLE true BUNDLE_EXTENSION "test")
main.c for completeness:
int main() { return 0; }
If you build with `cmake -GXcode . && cmake --build .` the output is "mytest.bundle", but if you build with `cmake . && cmake --build .` the output is "mytest.test".
It appears the `WRAPPER_EXTENSION` Xcode setting is not getting applied. The current workaround is:
set_target_properties(mytest PROPERTIES XCODE_ATTRIBUTE_WRAPPER_EXTENSION "test")
3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/14742Add a FRAMEWORK_SUFFIX or FRAMEWORK_EXTENSION property to change .framework2018-12-07T09:58:07-05:00Kitware RobotAdd a FRAMEWORK_SUFFIX or FRAMEWORK_EXTENSION property to change .frameworkThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14742). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14742). Further discussion may take place here.3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/13662CPack needs a replacement for the PackageMaker generator2018-12-07T09:58:48-05:00Kitware RobotCPack needs a replacement for the PackageMaker generatorThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13662). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13662). Further discussion may take place here.3.7.0https://gitlab.kitware.com/cmake/cmake/-/issues/13532kitware-provided CMake installer/executables should be codesigned with 'Devel...2018-12-07T09:58:53-05:00Kitware Robotkitware-provided CMake installer/executables should be codesigned with 'Developer ID' for GateKeeper on OS XThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13532). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13532). Further discussion may take place here.3.7.0Brad KingBrad King