CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-08-17T13:52:03-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/23854file(GET_RUNTIME_DEPENDENCIES) logic for `@loader_path` is incomplete2022-08-17T13:52:03-04:00Seth R Johnsonfile(GET_RUNTIME_DEPENDENCIES) logic for `@loader_path` is incomplete`cmBinUtilsMacOSMachOLinker::ScanDependencies` assumes that the replacement for `@loader_path` when resolving RPATHs is simply the parent directory of the library being scanned. *However*, if the library is embedded as part of a framewor...`cmBinUtilsMacOSMachOLinker::ScanDependencies` assumes that the replacement for `@loader_path` when resolving RPATHs is simply the parent directory of the library being scanned. *However*, if the library is embedded as part of a framework (as in `/PREFIX/lib/QtGui.framework/Versions/Versions/5/QtGui`), the loader path should be the parent directory of the *framework* rather than the binary library file (should be `/PREFIX/lib` but CMake sets `loaderPath = /PREFIX/lib/QtGui.framework/Versions/Versions/5`). This causes libraries like Qt that load fine through `dyld` to be rejected by CMake:
```
CMake Error at cmake_install.cmake:209 (file):
file Could not resolve runtime dependencies:
@rpath/QtCore.framework/Versions/5/QtCore
@rpath/QtGui.framework/Versions/5/QtGui
@rpath/QtWidgets.framework/Versions/5/QtWidgets
```
From the `dyld` documentation:
```
@loader_path/
This variable is replaced with the path to the directory
containing the mach-o binary which contains the load command using
@loader_path. Thus, in every binary, @loader_path resolves to a
different path, whereas @executable_path always resolves to the
same path. @loader_path is useful as the load path for a
framework/dylib embedded in a plug-in, if the final file system
location of the plugin-in unknown (so absolute paths cannot be
used) or if the plug-in is used by multiple applications (so
@executable_path cannot be used). If the plug-in mach-o file is at
/some/path/Myfilter.plugin/Contents/MacOS/Myfilter and a framework
dylib file is at
/some/path/Myfilter.plugin/Contents/Frameworks/Foo.framework/Versions/A/Foo,
then the framework load path could be encoded as
@loader_path/../Frameworks/Foo.framework/Versions/A/Foo and the
Myfilter.plugin directory could be moved around in the file system
and dyld will still be able to load the embedded framework.
```
@ben.boeckel @kyle.edwards
(I had to add a lot of debugging code to diagnose what libraries were failing and why... so it would be really nice to have some improved failure messages too ;) )https://gitlab.kitware.com/cmake/cmake/-/issues/23621_CURRENT_OSX_VERSION should be settable from command line2022-06-13T15:24:36-04:00Heiko Lewin_CURRENT_OSX_VERSION should be settable from command lineCross-compiling from linux to apple, in the current form, requires a little workaround: `Modules/Platform/Darwin-Initialize.cmake` executes `sw_vers` to query the MacOS version used for compiling. That tool is not present on linux system...Cross-compiling from linux to apple, in the current form, requires a little workaround: `Modules/Platform/Darwin-Initialize.cmake` executes `sw_vers` to query the MacOS version used for compiling. That tool is not present on linux systems, of course. This causes some problems as some checks compare the returned value to decide if e.g. the OS knows @rpath.
This can be worked around easily by putting a 'sw_vers'-script that just echoes a high-enough version in PATH.
It would be nicer, though, if a version to be assumed could be passed by command line, by e.g. something like `cmake -DCMAKE_OSX_VERSION_OVERRIDE=10.15`
I would be willing to work on this, but would like to first hear opinions on the naming on the variable.
e.g. `OSX_VERSION_OVERRIDE` could be mistaken as defining the target system versionhttps://gitlab.kitware.com/cmake/cmake/-/issues/23431cmake_host_system_information returns wrong results on M1 macs2022-04-20T13:23:27-04:00autoantwortcmake_host_system_information returns wrong results on M1 macsThe CPU features are only set for intel CPUs on macOS and not for other CPU types. This results in the wrong result for `HAS_FPU`, which returns false, but the M1 has an FPU.The CPU features are only set for intel CPUs on macOS and not for other CPU types. This results in the wrong result for `HAS_FPU`, which returns false, but the M1 has an FPU.https://gitlab.kitware.com/cmake/cmake/-/issues/23408Direct support for enabling bitcode on Apple platforms2022-04-11T08:51:10-04:00Craig ScottDirect support for enabling bitcode on Apple platformsEnabling bitcode for Apple platforms is problematic (for example, see #23390, #22961). We currently hard-code adding `-Wl,-headerpad_max_install_names` to linker flags on Apple platforms, but this conflicts with options like `-fembed-bit...Enabling bitcode for Apple platforms is problematic (for example, see #23390, #22961). We currently hard-code adding `-Wl,-headerpad_max_install_names` to linker flags on Apple platforms, but this conflicts with options like `-fembed-bitcode`, `-fembed-bitcode-marker` or `-bitcode_bundle`. The linker emits a warning that it will ignore `-headerpad_max_install_names` when any of those other flags are also given. This in turn defeats logic in the various `CheckXXXCompilerFlags` and `CheckLinkerFlags` modules, which relies on compile and link being warning-free.
Because CMake is forcing the `-Wl,-headerpad_max_install_names` flag onto projects, it is very difficult for them to engineer an arrangement that works with bitcode enabled. CMake should provide direct support for enabling bitcode and it should then not add `-Wl,-headerpad_max_install_names` if it will conflict.
As additional info, the relevant project setting for Xcode is `ENABLE_BITCODE`. When building directly, that will result in `-fembed-bitcode-marker` being added, while for an Archive operation, it will add `-fembed-bitcode` instead (see [this thread](https://developer.apple.com/forums/thread/3971) in the Apple developer forums for useful information). If the user wants to force using `-fembed-bitcode` for regular builds instead of `-fembed-bitcode-marker`, the linked discussion provides a couple of ways they can do that (i.e. the `DEPLOYMENT_PROCESSING` or `BITCODE_GENERATION_MODE` settings). It is debatable whether we want to support that secondary configurability, supporting just `ENABLE_BITCODE` might be enough. However, for other generators, we would have to pick which flag to add (`-fembed-bitcode` or `-fembed-bitcode-marker`), so we might end up needing to add that secondary support anyway in order to provide the required flexibility for them.https://gitlab.kitware.com/cmake/cmake/-/issues/23386FILE_SET functionality is unaware of frameworks2022-04-07T09:15:26-04:00Craig ScottFILE_SET functionality is unaware of frameworksThe new FILE_SET functionality in CMake 3.23 provides the ability to install headers with paths relative to a base directory. This makes the approach superior to the capabilities provided by `PUBLIC_HEADER` and `PRIVATE_HEADER`, which fl...The new FILE_SET functionality in CMake 3.23 provides the ability to install headers with paths relative to a base directory. This makes the approach superior to the capabilities provided by `PUBLIC_HEADER` and `PRIVATE_HEADER`, which flatten directory structures. Unfortunately, it appears that file sets do not mix well with framework library targets. When a HEADER file set is defined on a framework target, CMake has all the information needed to copy PUBLIC and INTERFACE header files to a framework's `Headers` directory, and copy PRIVATE header files to a framework's `PrivateHeaders` directory. This is something that should happen at _build_ time, not install time. A framework may later be installed using `install(TARGET)`, which installs the whole framework, including its headers (this was already the pre-existing behavior before file sets came along). At the moment, file sets do _not_ copy headers into a framework at build time, which seems like an oversight.
If a `FILE_SET` is listed in the `install(TARGETS)` command and the target is a framework, there's a good argument against that file set's headers being explicitly installed. Any headers already in the framework will be installed as part of the `FRAMEWORK` block of the `install()` command. Unfortunately, as of CMake 3.23.0, such file sets _will_ be installed, but the install destination is not relative to the framework but rather to the main base install location. For a framework header, the actual install location should be under paths of the form `SomeName.framework/Version/A/Headers` or `SomeName.framework/Version/A/PrivateHeaders` (note that the `A` could be something else, controlled by the `FRAMEWORK_VERSION` target property). For added complexity, if the project is cross-platform and the target will be an ordinary library on non-Apple platforms, then the file set will very likely have `SomeName` at the start of its relative paths. But frameworks have special rules around how `#include` works. Consider the following example:
```
#include <SomeName/blah.h>
```
If the compiler command line has a `-F` option pointing at the parent of the `SomeName.framework` directory, then an `#include` line like the above would find a header located at `SomeName.framework/Headers/blah.h` (there are usually symlinks created which would map `SomeName.framework/Headers` to `SomeName.framework/Versions/Current/Headers`). If header file sets _did_ copy the headers into the framework at build time, they would also need to strip off the leading `SomeName`, if present, to make this expected pattern work.
As issues like #16739 highlight, being able to preserve paths for headers copied into frameworks is definitely something users have wanted. While it is not "the Apple way", it is nonetheless very desirable (and valid) for cross-platform projects. The PUBLIC_HEADER and PRIVATE_HEADER functionality doesn't provide for that, which forces projects to do things manually with the `MACOSX_PACKAGE_LOCATION` source file property instead. That seems like a wart that file sets should have been able to remove, but we appear to have overlooked frameworks in the design and implementation. That decreases the value of file sets for multi-platform projects that provide libraries as frameworks on Apple platforms.
I'm not sure what our options are from here. On the one hand, I would consider these things to be bugs in the file sets implementation. They actively do the wrong thing for framework targets. But now that 3.23.0 has been released, projects may start implementing workarounds to try to (ab)use file sets to still install headers into frameworks as at least a partial solution. Those workarounds might have the potential to break if we fix the problems identified above. I suspect we're stuck with this for 3.23 and would need a policy to provide the more complete and consistent behavior in 3.24.
CC: @kyle.edwards @bbrown105https://gitlab.kitware.com/cmake/cmake/-/issues/23153macOS: Per-taget OSX_DEPLOYMENT_TARGET property2023-02-14T17:25:25-05:00Harry MallonmacOS: Per-taget OSX_DEPLOYMENT_TARGET propertyI don't know whether this would work but it would be useful to have `OSX_DEPLOYMENT_TARGET` as a target property, so that I can have e.g. a library with an old deployment target and a utility with a target allowing me to use newer featur...I don't know whether this would work but it would be useful to have `OSX_DEPLOYMENT_TARGET` as a target property, so that I can have e.g. a library with an old deployment target and a utility with a target allowing me to use newer features in the same project.
Would that be useful to others? Should that be possible?https://gitlab.kitware.com/cmake/cmake/-/issues/22997Add @executable_path/../Frameworks to install RPATH of macOS app targets2021-12-09T22:42:34-05:00Craig ScottAdd @executable_path/../Frameworks to install RPATH of macOS app targetsIt's a bit of a nuisance that for every macOS executable target that is an app bundle, we always end up having to add `@executable_path/../Frameworks` to the install RPATH (and often to the build RPATH as well). I'd like to proposed that...It's a bit of a nuisance that for every macOS executable target that is an app bundle, we always end up having to add `@executable_path/../Frameworks` to the install RPATH (and often to the build RPATH as well). I'd like to proposed that we add it automatically for macOS app executable targets, at least to the `INSTALL_RPATH` target property. I'd be open to automatically adding it to the `BUILD_RPATH` property as well. This would mean one less bit of boilerplate projects would have to add for a common case.
For apps that don't embed any frameworks, having `@executable_path/../Frameworks` added to the install or build RPATH anyway shouldn't do any harm. It won't be used in that case, but it won't break anything or change behavior.
I don't know if we'd need a policy for this. While it would be an observable change, I'd question whether it is a change that could make a practical difference to existing projects. We could look at the final RPATH at generation time and only add `@executable_path/../Frameworks` if it isn't already present. If we do add it, then we can add it to the end of the resolved RPATH. That way, we shouldn't create any danger of changing what gets found due to any pre-existing `INSTALL_RPATH` contents. An app bundle shouldn't be looking outside of the bundle itself for anything other than in system locations. But if we want to be ultra-conservative, I wouldn't push back on using a policy.
For iOS app bundles, potentially we might want to do something similar. I think the equivalent path would be just `@executable_path` in that case, but I don't have a lot of experience with shared frameworks on iOS to know if there would be any undesirable side effects from doing that.https://gitlab.kitware.com/cmake/cmake/-/issues/22760macOS: INTERFACE_SOURCES and bundling resources in consumers2021-10-14T10:58:52-04:00ChristophemacOS: INTERFACE_SOURCES and bundling resources in consumersHi,
I've an `INTERFACE` library that needs to copy files into a macOS bundle executable **before** Xcode codesigning step (POST_BUILD custom command is not an option). I believe the correct way to handle this is to set the `INTERFACE_SO...Hi,
I've an `INTERFACE` library that needs to copy files into a macOS bundle executable **before** Xcode codesigning step (POST_BUILD custom command is not an option). I believe the correct way to handle this is to set the `INTERFACE_SOURCES` target property and set the source property `MACOSX_PACKAGE_LOCATION` for the files I want to be copied into the bundle during Xcode build copy step (which happens before code signing).
Unfortunately set_source_files_properties is scope limited. Also the new `DIRECTORY` option is not solving the issue as the interface library has no way of knowing all the folders it will be used in (the library is consumed by other targets).
As an example, consider the following:
```cmake
cmake_minimum_required(VERSION 3.19)
project(test LANGUAGES CXX VERSION 1.0.0.1)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
# Include definition for an interface library
add_subdirectory(interfaceLib)
## Main app consuming the interface library (possibly in a sub folder)
add_executable(app MACOSX_BUNDLE app.cpp)
target_link_libraries(app PRIVATE interfaceLibrary)
```
and the interface library script:
```cmake
## Interface lib
set(INT_FILE_PATH "${CMAKE_CURRENT_LIST_DIR}/myFile.txt")
set_source_files_properties(${INT_FILE_PATH} PROPERTIES MACOSX_PACKAGE_LOCATION MyDataFolder)
add_library(interfaceLibrary INTERFACE IMPORTED GLOBAL)
set_target_properties(interfaceLibrary PROPERTIES INTERFACE_SOURCES "${INT_FILE_PATH}")
```
Possible fixes:
- add a `PARENT_SCOPE` keyword to set_source_files_properties that will define the source properties to the parent as well (and forward down the tree afterwards)
- add a `TARGET_SCOPE` keyword to set_source_files_properties that will define the source properties everywhere the target using this source file is consumed
- automatically globally set source properties when they are linked to a target property (maybe it's just MACOSX_PACKAGE_LOCATION that requires this)
Any other possibility?
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/22738macOS: find_library should maybe consider library architecture2022-03-01T07:52:43-05:00Sean McBridemacOS: find_library should maybe consider library architectureI run several macOS buildbots that build several open source projects. Yesterday I installed [MacPorts](https://www.macports.org/) on them and installed a few ports (notably `subversion`). This tool places files in `/opt/local/lib` and ...I run several macOS buildbots that build several open source projects. Yesterday I installed [MacPorts](https://www.macports.org/) on them and installed a few ports (notably `subversion`). This tool places files in `/opt/local/lib` and `/opt/local/include`. In particular, it so happened to install `/opt/local/lib/libmagic.dylib`.
One project I build nightly is [GDCM](http://gdcm.sourceforge.net/wiki/index.php/Main_Page) and it was building yesterday but [failed today](https://open.cdash.org/viewBuildError.php?buildid=7501364) with:
```
[CTest: warning matched] ld: warning: ignoring file /opt/local/lib/libmagic.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
"_magic_close", referenced from:
_main in EncapsulateFileInRawData.cxx.o
"_magic_file", referenced from:
_main in EncapsulateFileInRawData.cxx.o
"_magic_open", referenced from:
_main in EncapsulateFileInRawData.cxx.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
This build of GDCM specifies `CMAKE_OSX_ARCHITECTURES=x86_64;arm64` (i.e. a Universal Binary). MacPorts installed x86_64-only on this Intel Mac. `find_library` found the existence of a file at `/opt/local/lib/libmagic.dylib` but it seems it doesn't check what architectures the found file contains, and whether they align with what my build specifies in `CMAKE_OSX_ARCHITECTURES`. libmagic is optional for GDCM, so yesterday it found nothing, and built fine. Today it found an Intel-only version from MacPorts and the universal build is broken.
Perhaps `find_library` should use `file` or `otool` to preflight the libs it finds?https://gitlab.kitware.com/cmake/cmake/-/issues/22669macOS: CMake uses -Wl,-rpath for Mac OS X 10.4 Tiger despite not being supported2024-02-14T09:07:01-05:00Thomas Siracktsirack@protonmail.commacOS: CMake uses -Wl,-rpath for Mac OS X 10.4 Tiger despite not being supportedThis issue stemmed from a build failure in another software project; see [https://github.com/minetest/minetest/issues/11647](https://github.com/minetest/minetest/issues/11647) for more information. Essentially, no matter what I tried aft...This issue stemmed from a build failure in another software project; see [https://github.com/minetest/minetest/issues/11647](https://github.com/minetest/minetest/issues/11647) for more information. Essentially, no matter what I tried after the fact, CMake was still trying to use `-Wl,-rpath` to link a test program for a library.
This included setting `CMAKE_OSX_DEPLOYMENT_TARGET` to `10.4`, `CMAKE_SKIP_RPATH` to `TRUE` and `CMAKE_MACOSX_RPATH` to `FALSE`, but again, nothing changed.
Looking at the CMake file for Darwin (macOS), I found this:
```cmake
if(NOT "${_CURRENT_OSX_VERSION}" VERSION_LESS "10.5")
set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")
endif()
```
From the looks of it, this should only be enabling `-rpath` if the macOS version is _not less_ (i.e. greater than or equal to) 10.5. It appears, however, to be completely ignored.
In desperation, I forcibly modified this file to set `CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG` to an empty string. While this did get zstd in the project to be detected, it still did not complete successfully.
```
Thomass-iMac:build thomas$ cmake .. -DCMAKE_OSX_DEPLOYMENT_TARGET="10.4" -DCMAKE_SKIP_RPATH=TRUE -DCMAKE_SKIP_BUILD_RPATH=TRUE -DCMAKE_MACOSX_RPATH=FALSE -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk/ -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/opt/irrlichtmt/ppc -DCMAKE_TOOLCHAIN_FILE=/Users/thomas/Documents/minetest/ppctoolchain.cmake -DCMAKE_INSTALL_PREFIX=/Users/thomas/Documents/minetest-built -DZSTD_INCLUDE_DIR=/opt/zstd/ppc/include -DZSTD_LIBRARY=/opt/zstd/ppc/lib/libzstd.dylib -DBUILD_UNITTESTS=FALSE -DENABLE_CURL=OFF -DENABLE_CURSES=OFF -DENABLE_FREETYPE=OFF -DENABLE_GETTEXT=OFF -DENABLE_LEVELDB=OFF -DENABLE_POSTGRESQL=OFF -DENABLE_REDIS=OFF -DENABLE_SPATIAL=OFF -DENABLE_SOUND=OFF -DENABLE_LUAJIT=OFF -DVERSION_EXTRA="powerpc"
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /opt/gcc/ppc/11/bin/powerpc-apple-darwin8-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/gcc/ppc/11/bin/powerpc-apple-darwin8-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- *** Will build version 5.5.0-powerpc ***
-- Found IrrlichtMt 1.9.0
-- Using GMP provided by system.
-- Found GMP: /opt/gmp/ppc/lib/libgmp.dylib
-- Using JsonCpp provided by system.
-- Found Json: /opt/jsoncpp/ppc/lib/libjsoncpp.dylib
-- LuaJIT detection disabled! (ENABLE_LUAJIT=0)
-- LuaJIT not found, using bundled Lua.
CMake Warning at src/CMakeLists.txt:53 (message):
cURL is required to load the server list
-- GetText disabled.
-- Found OpenGL: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework
-- Found SQLite3: /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.dylib
-- Prometheus client disabled.
-- Found ZLIB: /opt/zlib/ppc/lib/libz.dylib (found version "1.2.11")
-- Looking for ZSTD_initCStream
-- Looking for ZSTD_initCStream - found
-- Found Zstd: /opt/zstd/ppc/lib/libzstd.dylib
-- Looking for include file endian.h
-- Looking for include file endian.h - not found
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
CMake Error at /opt/irrlichtmt/ppc/lib/cmake/IrrlichtMt/IrrlichtMtTargets.cmake:54 (add_library):
Attempting to use @rpath without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being
set. This could be because you are using a Mac OS X version less than 10.5
or because CMake's platform configuration is corrupt.
Call Stack (most recent call first):
/opt/irrlichtmt/ppc/lib/cmake/IrrlichtMt/IrrlichtMtConfig.cmake:11 (include)
CMakeLists.txt:88 (find_package)
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
```https://gitlab.kitware.com/cmake/cmake/-/issues/22372macOS: Linker-signed libraries signed at install-time crash with hardened run...2022-01-04T18:35:38-05:00Ryan FostermacOS: Linker-signed libraries signed at install-time crash with hardened runtimeWhen using hardened runtime for an application, macOS will enforce termination of a process that tries to load libraries that failed library validation checks. Among those tests is a comparison between the file modification timestamp and...When using hardened runtime for an application, macOS will enforce termination of a process that tries to load libraries that failed library validation checks. Among those tests is a comparison between the file modification timestamp and its code-signing timestamp.
On modern macOS systems, maybe due to APFS, this leads to a situation where a library created with an ad-hoc code-signature (e.g., to be loaded/run from the build tree on Apple Silicon Macs), which is then `install`-ed into its final destination (i.e., inside an app bundle), has its `rpath`-entries fixed up, and gets finally code-signed with the actual developer ID, results in crashing the loading application because the second code-signing leads to a "tampered" library.
There is a radar filed for this behavior (https://openradar.appspot.com/FB8914243), but in informal talks with Apple this was confirmed as not a bug, but intended behavior: a code-signed library cannot be code-signed again at a later date and used in hardened runtime environments.
Apple suggested using `ditto` to copy the library before fixing it up and code-signing it to ensure that macOS will treat it as a separate file.
As such it would be desirable if CMake itself could ensure that for file copy operations or `install` targets actual clones are created to avoid this issue.
Noticeably, macOS will terminate the application on launch and even though the fixed library has been put _into_ the application bundle, the crash log points to the same library in the build tree as the library that failed validation.https://gitlab.kitware.com/cmake/cmake/-/issues/22184Xcode: OSX_DEPLOYMENT_TARGET should depend on target architecture2022-09-03T09:53:06-04:00EikeAtOTXcode: OSX_DEPLOYMENT_TARGET should depend on target architectureWhen building a CMake project for multiple architectures (x86_64 and arm64) on Mac it should be possible to set the minimum macOS version depending on the architecture.
Reasoning:
The first macOS version ever supporting the Apple Silico...When building a CMake project for multiple architectures (x86_64 and arm64) on Mac it should be possible to set the minimum macOS version depending on the architecture.
Reasoning:
The first macOS version ever supporting the Apple Silicon (ARM) architecture was macOS 11.0. Accordingly all sources compiled for Apple Silicon need to be compiled with `'-target arm64-apple-macos11.0'`. However, the x86_64 variant in the universal binary should be able to support macOS versions down to 12.0. Currently the OSX_DEPLOYMENT_TARGET is set unconditionally, which either:
- leads to compilation errors when building for arm64 against the 11.0 or higher SDKs
- prevents x86_64 code to run on a version older than 11.0
It should therefore be possible to specify the macOS target version based on the target architecture.https://gitlab.kitware.com/cmake/cmake/-/issues/21962Objective C/C++: macOS architecture depends on language initialization order2021-03-24T10:04:37-04:00Tim BlechmannObjective C/C++: macOS architecture depends on language initialization order```
cmake_minimum_required(VERSION 3.19)
project(foo LANGUAGES C CXX OBJC OBJCXX)
add_executable(main a.m b.c c.mm d.cpp)
```
when configuring with `CMAKE_OSX_ARCHITECTURES=arm64` the ninja projects will not pass the `-arch` compiler fl...```
cmake_minimum_required(VERSION 3.19)
project(foo LANGUAGES C CXX OBJC OBJCXX)
add_executable(main a.m b.c c.mm d.cpp)
```
when configuring with `CMAKE_OSX_ARCHITECTURES=arm64` the ninja projects will not pass the `-arch` compiler flag to objc sources:
```
[1/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/b.c.o -MF CMakeFiles/main.dir/b.c.o.d -o CMakeFiles/main.dir/b.c.o -c ../b.c
[2/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -x objective-c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -std=gnu++98 -MD -MT CMakeFiles/main.dir/c.mm.o -MF CMakeFiles/main.dir/c.mm.o.d -o CMakeFiles/main.dir/c.mm.o -c ../c.mm
[3/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -std=gnu11 -MD -MT CMakeFiles/main.dir/a.m.o -MF CMakeFiles/main.dir/a.m.o.d -o CMakeFiles/main.dir/a.m.o -c ../a.m
[4/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/d.cpp.o -MF CMakeFiles/main.dir/d.cpp.o.d -o CMakeFiles/main.dir/d.cpp.o -c ../d.cpp
```
observation: `a.m` is compiled without `-arch=arm64`.
---
if the `OBJC` language is not initialised, the source file is identified as `c` and the `-arch` flag is passed correctly.
---
funny observation: if the `OBJC` language is initialised **after** `C`, the `-arch` flag is passed correctly:
```
cmake_minimum_required(VERSION 3.19)
#project(foo LANGUAGES C CXX OBJC OBJCXX)
project(foo LANGUAGES OBJC OBJCXX C CXX)
add_executable(main a.m b.c c.mm d.cpp)
```
```
[1/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/a.m.o -MF CMakeFiles/main.dir/a.m.o.d -o CMakeFiles/main.dir/a.m.o -c ../a.m
[2/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/b.c.o -MF CMakeFiles/main.dir/b.c.o.d -o CMakeFiles/main.dir/b.c.o -c ../b.c
[3/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -x objective-c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -std=gnu++98 -MD -MT CMakeFiles/main.dir/c.mm.o -MF CMakeFiles/main.dir/c.mm.o.d -o CMakeFiles/main.dir/c.mm.o -c ../c.mm
[4/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/d.cpp.o -MF CMakeFiles/main.dir/d.cpp.o.d -o CMakeFiles/main.dir/d.cpp.o -c ../d.cpp
```https://gitlab.kitware.com/cmake/cmake/-/issues/21923Set CMAKE_(HOST_)?SYSTEM_NAME to macOS/iOS instead of Darwin2022-01-09T12:32:22-05:00Kyle EdwardsSet CMAKE_(HOST_)?SYSTEM_NAME to macOS/iOS instead of DarwinWhen applicable, `CMAKE_HOST_SYSTEM_NAME` and `CMAKE_SYSTEM_NAME` should be set to `macOS` or `iOS` as appropriate, instead of `Darwin`. We will need a policy for this.When applicable, `CMAKE_HOST_SYSTEM_NAME` and `CMAKE_SYSTEM_NAME` should be set to `macOS` or `iOS` as appropriate, instead of `Darwin`. We will need a policy for this.https://gitlab.kitware.com/cmake/cmake/-/issues/21885macOS: CMAKE_CROSSCOMPILING not set when building arm64 binaries on a x86_642021-03-24T10:04:49-04:00Maxime LeblancmacOS: CMAKE_CROSSCOMPILING not set when building arm64 binaries on a x86_64When trying to build `arm64` only binaries on a `x86_64` machine, the `CMAKE_CROSSCOMPILING` is not set to `TRUE`.
Therefore, checking if we are crosscompiling to avoid running macros such as `check_c_source_runs` will not work resultin...When trying to build `arm64` only binaries on a `x86_64` machine, the `CMAKE_CROSSCOMPILING` is not set to `TRUE`.
Therefore, checking if we are crosscompiling to avoid running macros such as `check_c_source_runs` will not work resulting in not setting some variables.
For me, `CMakeDetermineSystem.cmake` should, on macOS, check current arch as well as if `CMAKE_OSX_ARCHITECTURES` is set and determine wether we are cross-compiling or not.https://gitlab.kitware.com/cmake/cmake/-/issues/21854Xcode: Install-time editing with install_name_tool breaks signatures2022-01-04T16:10:30-05:00Brad KingXcode: Install-time editing with install_name_tool breaks signaturesWhen using the Xcode generator, install-time editing operations with `install_name_tool` warn:
```
install_name_tool: warning: changes being made to the file will invalidate the code signature in: ...
```
and break the signatures of bi...When using the Xcode generator, install-time editing operations with `install_name_tool` warn:
```
install_name_tool: warning: changes being made to the file will invalidate the code signature in: ...
```
and break the signatures of binaries. This occurs when editing binaries to change `LC_LOAD_DYLIB` names for dependencies, e.g. to switch to `@executable_path/...`.
This is particularly prevalent on macOS arm64 machines, where all tooling signs binaries (even if a local ad-hoc signature) and macOS requires all binaries to be signed before running.https://gitlab.kitware.com/cmake/cmake/-/issues/21845Xcode: POST_BUILD runs before signing, breaks builds on ARM Mac2024-03-02T16:35:04-05:00Brad KingXcode: POST_BUILD runs before signing, breaks builds on ARM MacWith the Xcode generator on macOS arm64, the pattern
```cmake
add_executable(myexe myexe.c)
add_custom_command(TARGET myexe POST_BUILD COMMAND myexe)
```
fails to build. The `POST_BUILD` command generates a "Run Script" build phase wi...With the Xcode generator on macOS arm64, the pattern
```cmake
add_executable(myexe myexe.c)
add_custom_command(TARGET myexe POST_BUILD COMMAND myexe)
```
fails to build. The `POST_BUILD` command generates a "Run Script" build phase with a script that runs `myexe`, but Xcode's build system tries to run that phase before singing the executable.
The build fails with output:
```
Killed: 9 "/path/to/myexe"
Command PhaseScriptExecution failed with a nonzero exit code
```https://gitlab.kitware.com/cmake/cmake/-/issues/21768macOS: App Bundle "Resouces" directory structure2021-02-04T09:18:38-05:00Ghost UsermacOS: App Bundle "Resouces" directory structureI literally spent 2 days on this already. Is simplest copy_directory is a way to do this?
What I mean I have a project structure
```
assets/subfolders + files
src/main.cpp
CMakeList.txt
```
CMakeList.txt
```
add_executable(hello src/mai...I literally spent 2 days on this already. Is simplest copy_directory is a way to do this?
What I mean I have a project structure
```
assets/subfolders + files
src/main.cpp
CMakeList.txt
```
CMakeList.txt
```
add_executable(hello src/main.cpp)
set_target_properties(hello PROPERTIES
MACOSX_BUNDLE TRUE
RESOURCE "??? folders / files ??? ")
```
Also I can't understand how to use it, what I mean such target properties generates hello.app, but "Resources" not shows up!
```
file(GLOB_RECURSE RES_SOURCES "${PROJECT_SOURCE_DIR}/assets/*")
add_executable(hello MACOSX_BUNDLE src/main.cpp ${RES_SOURCES}) #
SET_SOURCE_FILES_PROPERTIES(${RES_SOURCES} MACOSX_PACKAGE_LOCATION "Resources")
```
It does copy all res sources to "Resources" folder, but hierarchy is being lost!
Hope I can find some help here, thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/21734Add CPackProductbuild support for the hostArchitectures option in Distributio...2024-03-11T03:05:29-04:00Harry MallonAdd CPackProductbuild support for the hostArchitectures option in Distribution.xmlThe Distribution XML file contains a line called `options`. Current CMake choices are [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.3/Modules/Internal/CPack/CPack.distribution.dist.in).
```xml
<options allow-external-script...The Distribution XML file contains a line called `options`. Current CMake choices are [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.3/Modules/Internal/CPack/CPack.distribution.dist.in).
```xml
<options allow-external-scripts="no" customize="allow" rootVolumeOnly="false"></options>
```
However when building for Apple Silicon / x86_64 universal we want to set a sub-option in there `hostArchitectures` to `arm64,x86_64`. Referenced [here (but not updated for Apple Silicon)](https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html). Installers build with `arm64,x86_64` should not force Rosetta 2 installation on Apple Silicon macs.
`man productbuild` says that on 11.0 (Big Sur) the default is set to `arm64,x86_64` rather than Intel only and has other useful context.
Maybe we want the option to set it manually as arm64 installers will want `arm64` only, intel only will want `x86_64` and universal 2 will want `arm64,x86_64`?https://gitlab.kitware.com/cmake/cmake/-/issues/21719macOS: Optionally exclude weak dependencies from file(GET_RUNTIME_DEPENDENCIES)2021-03-31T12:02:52-04:00Brad KingmacOS: Optionally exclude weak dependencies from file(GET_RUNTIME_DEPENDENCIES)Discussion in https://gitlab.kitware.com/cmake/cmake/-/issues/21684#note_886225 concluded that we should add an option to `file(GET_RUNTIME_DEPENDENCIES)` and perhaps `BundleUtilities` to exclude "weak" dependencies on macOS.Discussion in https://gitlab.kitware.com/cmake/cmake/-/issues/21684#note_886225 concluded that we should add an option to `file(GET_RUNTIME_DEPENDENCIES)` and perhaps `BundleUtilities` to exclude "weak" dependencies on macOS.