CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-26T14:44:26-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/24408Xcode: Option to use Xcode default artifact locations2024-03-26T14:44:26-04:00Nick BrookXcode: Option to use Xcode default artifact locationsRecently, my Xcode project build by CMake started outputting the built library to the wrong directory. I determined this was because CMake is now setting the "CONFIGURATION_BUILD_DIR" property on the target. To get this to work how I nee...Recently, my Xcode project build by CMake started outputting the built library to the wrong directory. I determined this was because CMake is now setting the "CONFIGURATION_BUILD_DIR" property on the target. To get this to work how I need it to, the property can't be set to any value – it can't override the default value. If the property is set to anything, Xcode won't use its own value for the build directory.
This brings me to a wider point about CMake Xcode projects – there is no way to unset a default value that CMake uses, either on a target or globally in the project. You can't unset the target property, CMake uses its default value. You can't set the property to an empty string, as the property is then set to an empty string in the Xcode project. This makes it impossible to achieve certain things with CMake Xcode projects. Unless I've missed a way it can be done?
Perhaps a certain string could be used in Xcode attribute properties to instruct CMake not to set a value for the property, e.g. "<XCODE_DEFAULT_VALUE>"? Or perhaps CMake should set its default values to the Xcode attribute variables/properties before CMakeLists is run, and after running CMakeLists, only the variables/properties that are still set are output to the generated project. In this way the existing mechanisms for unsetting variables/properties could be used.https://gitlab.kitware.com/cmake/cmake/-/issues/25775Xcode: Compile options applied to ASM files are not respected2024-03-14T13:02:39-04:00Joey TengXcode: Compile options applied to ASM files are not respected<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
Simple example:
```cmake
cmake_minimum_required(VERSION 3.16...3.28)
project(demo LANGUAGES C ASM)
add_executable(a a.S)
target_compile_options(a PRIVATE -DBUILD_AARCH64)
```
Expected behaviour (observed in Makefile generator, with `cmake --build build --verbose`
```
[ 50%] Building ASM object CMakeFiles/a.dir/a.S.o
/opt/homebrew/opt/ccache/libexec/cc -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -mmacosx-version-min=14.3 -DBUILD_AARCH64 -o CMakeFiles/a.dir/a.S.o -c /Users/demo/cmake-issue-demo/GAS_not_source_file/a.S
```
Undesired behaviour (observed in Xcode generator):
```
CompileC /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.o /Users/demo/cmake-issue-demo/GAS_not_source_file/a.S normal arm64 assembler-with-cpp com.apple.compilers.llvm.clang.1_0.compiler (in target 'a' from project 'demo')
cd /Users/demo/cmake-issue-demo/GAS_not_source_file
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x assembler-with-cpp -ivfsstatcache /var/folders/wx/p3kml5gn14s_5k6xp15qjtxc0000gn/C/com.apple.DeveloperTools/15.3-15E204a/Xcode/SDKStatCaches.noindex/macosx14.4-23E208-13f6e737bddbb37f317b3579f3535bf5.sdkstatcache -fmessage-length\=187 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -fcolor-diagnostics -Wno-trigraphs -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unuse
cmake_minimum_required(VERSION 3.16...3.28)
d-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-implicit-fallthrough -fstrict-aliasing -Wdeprecated-declarations -Wno-sign-conversion -Wno-infinite-recursion -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-semicolon-before-method-body @/Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/533656923a283fa776881f304837ed9e-common-args.resp -MMD -MT dependencies -MF /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.d --serialize-diagnostics /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.dia -c /Users/demo/cmake-issue-demo/GAS_not_source_file/a.S -o /Users/demo/cmake-issue-demo/GAS_not_source_file/build-Xcode/build/a.build/Debug/Objects-normal/arm64/a.o
```
Noticed that `-DBUILD_AARCH64` is missing.
The `a.S` file can contain anything (mine was a simple hello world C program generated via `gcc -S`), and the `-DBUILD_AARCH64` flag can be any compile option.
Test environment is M2 MacBook Pro running macOS 14.3.1 with CMake 3.28.3.
My question is: is there a plan to fix this? How can I help to fix this issue?https://gitlab.kitware.com/cmake/cmake/-/issues/25719CMAKE_XCODE_GENERATE_SCHEME should default to YES2024-03-12T11:52:19-04:00Dave AbrahamsCMAKE_XCODE_GENERATE_SCHEME should default to YESOr so I assert. A fully-functional Xcode project is more useful than one with no schemes and turning it on by default would prevent people from filing issues because they haven't discovered it.Or so I assert. A fully-functional Xcode project is more useful than one with no schemes and turning it on by default would prevent people from filing issues because they haven't discovered it.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/24399Xcode: Update project format compatibility level2024-02-21T09:31:18-05:00Paul Masri-StoneXcode: Update project format compatibility levelWhen `MACOSX_BUNDLE TRUE`, CMake generates an Xcode project.
Opening this in Xcode reveals that the project format is "Xcode 3.2-compatible". This is 9 versions behind the current "Xcode 14.0-compatible".
The problems with using such a...When `MACOSX_BUNDLE TRUE`, CMake generates an Xcode project.
Opening this in Xcode reveals that the project format is "Xcode 3.2-compatible". This is 9 versions behind the current "Xcode 14.0-compatible".
The problems with using such an old format are:
- The General tab does not get populated.
- This causes a problem accepting the icon and requires an (undocumented) extra step to manually set the App Icon.
- It is not possible to specify supported destinations (e.g. iPhone, iPad, etc.)
- Within the Build Settings tab, the Packaging section does not get fully populated
- This results in the warning "User-supplied CFBundleIdentifier 'my.identifier.from.info.plist' in the Info.plist must be the same as the PRODUCT_BUNDLE_IDENTIFIER build setting value ''."
- Within the Build Phases tab, asset catalogs don't get added to the Copy Bundle Resources section.
- This causes a problem accepting the assets, e.g. the app icon and requires an (undocumented) extra step to manually set the App Icon.
In addition,
- Apple documentation https://help.apple.com/xcode/mac/current/#/dev10510b1f7 it says "For iOS 11.0 apps and later, the app icon is required to be in an asset catalog." It would be helpful if CMake could provide a way to specify an asset catalog by its folder `MyAssetName.xcassets` and have the whole asset copied into the target Resource folder _retaining its internal folder structure_.
I have looked at this just from the perspective of building iOS apps. Maybe there are other impacts for MacOS, TVOS, WatchOS apps.
This issue is related to the need to update the Info.plist handling: https://gitlab.kitware.com/cmake/cmake/-/issues/24169https://gitlab.kitware.com/cmake/cmake/-/issues/22569Xcode: CMake does not generate projects with suitable architecture settings f...2024-02-17T20:56:08-05:00Jeremy AgostinoXcode: CMake does not generate projects with suitable architecture settings for Universal productsMy team uses CMake to build a cross platform application bundle consisting of several executables and shared libraries. Our target platforms are Windows x86, Windows x86_64, macOS x86_64 and macOS arm64. For Mac targets we use the Xcode ...My team uses CMake to build a cross platform application bundle consisting of several executables and shared libraries. Our target platforms are Windows x86, Windows x86_64, macOS x86_64 and macOS arm64. For Mac targets we use the Xcode generator and the xcodebuild tool to build an "archive" and export valid, signed products. When arm64 Macs were released by Apple and we needed to start building a "universal" (fat binary) application for macOS we ran into issues with CMake.
The Xcode projects generated by CMake with default settings do not produce fat binaries when built on either x86_64 or arm64 hosts. I attached projects that show an example of this. Examine "build output.txt" to find that for an x86_64 host it builds an x86_64-only binary and for an arm64 host, it builds an arm64-only binary.
[test-default-arch-settings-arm64_host.zip](/uploads/6f433fa0c24ae46d1c642d2d39241ccd/test-default-arch-settings-arm64_host.zip)
[test-default-arch-settings-x86_host.zip](/uploads/dd5c99d5a5cdb7cdd247e79c8307e9d5/test-default-arch-settings-x86_host.zip)
The CMake documentation describes `CMAKE_OSX_ARCHITECTURES` and we tried setting this at configure time. See sample project. This setting has a couple undesirable outcomes. One is that the Xcode setting `ONLY_ACTIVE_ARCH` gets set to `NO` for every single individual target in the product. This means that even when our toolchain is building in _Debug_ configuration for testing purposes, the build time is effectively twice as long because it builds an architecture that is not needed. The other issue is that because the `ARCHS` and `ONLY_ACTIVE_ARCH` Xcode settings are changed at every individual target level, it's not possible to override them with a global project setting.
[test-recommended-arch-settings-x86_host.zip](/uploads/7a4acc5f85ab5027c6ca6283e72a42e1/test-recommended-arch-settings-x86_host.zip)
We determined that it was possible to set Xcode global project settings with CMake variables to achieve the highly desired outcome of _Debug_ configurations building only for host architecture and _Release_ configurations building all supported architectures. Xcode itself uses macros to define which architectures make sense for a given platform:
```
set(CMAKE_XCODE_ATTRIBUTE_ARCHS[variant=Debug] "$(NATIVE_ARCH_ACTUAL)")
set(CMAKE_XCODE_ATTRIBUTE_ARCHS[variant=MinSizeRel] "$(ARCHS_STANDARD)")
set(CMAKE_XCODE_ATTRIBUTE_ARCHS[variant=RelWithDebInfo] "$(ARCHS_STANDARD)")
set(CMAKE_XCODE_ATTRIBUTE_ARCHS[variant=Release] "$(ARCHS_STANDARD)")
set(CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH NO)
```
This combination of options works sufficiently for an x86_64 host. The Xcode project has host-only arch enabled for debug and all supported archs defined for release. It also only has arch settings defined for the global project level and not individual target level, so targets can have their arch settings overridden more easily when needed. The "build output.txt" shows that an archive build produces a fat binary.
[test-overriden-arch-settings-x86_host.zip](/uploads/59bd2fa7f5d966af7e955e6a6241ec2d/test-overriden-arch-settings-x86_host.zip)
However these settings do *not* work on arm64 hosts for reasons that are not clear. If you examine the attached generated project, both the global and individual target settings have been overridden to "arm64" for all configurations. It appears that CMake is completely ignoring the `CMAKE_XCODE_ATTRIBUTE_ARCHS` values which I have to assume is a defect.
[test-overriden-arch-settings-arm64_host.zip](/uploads/e77cfcd62c1424d73e493153ad8ceb6e/test-overriden-arch-settings-arm64_host.zip)
Overall, to a Mac-native developer like me, CMake's multi-arch support on macOS seems to be a mess. If you use Xcode to create a project it defaults to some very sensible settings. At the global project level, `ARCHS = $(ARCHS_STANDARD)` and `ONLY_ACTIVE_ARCH` is `YES` for _Debug_ and `NO` for _Release_. Out of the box, target settings inherit from the project. I could not find any way to replicate this setup in CMake. In particular, it's very frustrating that changing the `CMAKE_OSX_ARCHITECTURES` settings makes it apply changes to every single individual target. In a project where some targets need to only target a single architecture and where _Debug_ should always only build the host architecture, the CMake options for Xcode target architecture are unhelpful at best.
I really think the best solution is for CMake to by default produce an Xcode project that is set up similarly to how Xcode itself creates projects. That means at the global level, the `ARCHS` value is *not set at all* and `ONLY_ACTIVE_ARCH` is `YES` for _Debug_ and `NO` for _Release_. At the target level, either of those settings should only exist if there was an explicit directive in the CMake target via `set_target_properties` for example. If you look at a freshly created Xcode _pbxproj_ file there are very few individual target and even global project settings explicitly set other than warnings flags, because the defaults make sense.https://gitlab.kitware.com/cmake/cmake/-/issues/24302Xcode: Metal shaders are not added to Target Membership, resulting in their e...2024-02-11T21:43:05-05:00rnbhattXcode: Metal shaders are not added to Target Membership, resulting in their exclusion from the build.When adding Metal shader files via `add_executable`, the shaders are not added to the Xcode target membership. This means that when compiling the target, the metal shaders are excluded, which causes Metal calls to load shaders to fail (r...When adding Metal shader files via `add_executable`, the shaders are not added to the Xcode target membership. This means that when compiling the target, the metal shaders are excluded, which causes Metal calls to load shaders to fail (return nil). Below is a minimal example which reproduces the issue (also attached as a zip at the bottom of this report).
`CMakeLists.txt`
```cmake
cmake_minimum_required(VERSION 3.24)
project(bug_report)
# enable obj-c++ for the sample code
add_definitions("-x objective-c++")
# add an executable with the obj-c++ file and a metal shader
add_executable(${PROJECT_NAME} main.mm shader.metal)
set_target_properties(${PROJECT_NAME} PROPERTIES
MACOSX_BUNDLE TRUE
)
# link to metal for sample code
find_library(METAL_LIB Metal REQUIRED)
target_link_libraries(${PROJECT_NAME} PRIVATE ${METAL_LIB})
```
`main.mm`
```cpp
#include <iostream>
#include <stdexcept>
#import <Metal/Metal.h>
int main(){
auto device = MTLCreateSystemDefaultDevice();
auto library = [device newDefaultLibrary];
if (library == nullptr){
std::cerr << "ERROR: Could not create default library - shader.metal was probably not included in the target membership." << std::endl;
return 1;
}
std::cout << "Loaded default library" << std::endl;
auto shader = [library newFunctionWithName:@"shaderfunc"];
if (shader == nullptr){
std::cerr << "ERROR: Could not create function - shader.metal was probably not included in the target membership." << std::endl;
return 1;
}
std::cout << "SUCCESS: Loaded shader and library!" << std::endl;
return 0;
}
```
`shader.metal`
```glsl
vertex void shaderfunc(){
}
```
When using `cmake -G "Xcode" ..`, `main.mm` is added to the `bug_report` target:
<img src="/uploads/2d8e18c1010f1333e04c5e5d2c6af22d/image.png" width="250">
However, `shader.metal` is not included in the target membership:
<img src="/uploads/aa1f1d472ccb818466d942e44d82d1f1/image.png" width="250">
When `bug_report` is compiled and ran, it produces the following output:
```
ERROR: Could not create default library - shader.metal was probably not included in the target membership.
```
If I manually enable target membership for `shader.metal` in the sidebar, then compile and run `bug_report`, it produces the following output:
```
Loaded default library
SUCCESS: Loaded shader and library!
```
<img src="/uploads/c1c2c4c6a4e1e1b86f630c35054967ba/image.png" width="250">
I think CMake should add `.metal` files to the Target Membership automatically, since at present every time a CMake configure is run the shaders lose their target membership. In addition, one cannot easily enable the target membership manually for headless CI builds.
I have attached a zip file containing everything needed to reproduce the issue.
[bug_repro.zip](/uploads/46366e61df7afd7d57235ba66b930d0c/bug_repro.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/24020CTest is incompatible with XCODE_EMIT_EFFECTIVE_PLATFORM_NAME = ON2024-02-02T08:20:58-05:00Harry MallonCTest is incompatible with XCODE_EMIT_EFFECTIVE_PLATFORM_NAME = ONWhen global property `XCODE_EMIT_EFFECTIVE_PLATFORM_NAME` is ON (or we are using iOS / tvOS / watchOS where it is ON by default) the CTestTestfile.cmake ends up with an escaped `\${EFFECTIVE_PLATFORM_NAME}` in its file path, which is not...When global property `XCODE_EMIT_EFFECTIVE_PLATFORM_NAME` is ON (or we are using iOS / tvOS / watchOS where it is ON by default) the CTestTestfile.cmake ends up with an escaped `\${EFFECTIVE_PLATFORM_NAME}` in its file path, which is not correct and results in a `Could not find executable` error.
e.g. `/Users/username/Development/cmake/build/Tests/RunCMake/XcodeProject/XcodeMultiplatform-build/Debug\${EFFECTIVE_PLATFORM_NAME}/main.app/Contents/MacOS/main`
I was looking at this as I want to run CTest with iOS and this is the flipside of https://gitlab.kitware.com/cmake/cmake/-/issues/23970 (but they are not the same issue). I cannot test with iOS with the Xcode generator (Makefiles are fine) without fixing one or the other.
The following diff adds a test for this.
```diff
diff --git a/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake b/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
index fde8cc9152..8e31f12648 100644
--- a/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
+++ b/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
@@ -358,6 +358,7 @@ if(NOT XCODE_VERSION VERSION_LESS 5)
run_cmake_command(XcodeMultiplatform-macosx-build ${CMAKE_COMMAND} --build . -- -sdk macosx)
run_cmake_command(XcodeMultiplatform-macosx-install ${CMAKE_COMMAND} --build . --target install -- -sdk macosx DESTDIR=${RunCMake_TEST_BINARY_DIR}/_install_macosx)
+ run_cmake_command(XcodeMultiplatform-macosx-test ${CMAKE_COMMAND} --build . --target RUN_TESTS -- -sdk macosx)
unset(RunCMake_TEST_BINARY_DIR)
unset(RunCMake_TEST_NO_CLEAN)
diff --git a/Tests/RunCMake/XcodeProject/XcodeMultiplatform.cmake b/Tests/RunCMake/XcodeProject/XcodeMultiplatform.cmake
index a1064f45dc..7dc7529307 100644
--- a/Tests/RunCMake/XcodeProject/XcodeMultiplatform.cmake
+++ b/Tests/RunCMake/XcodeProject/XcodeMultiplatform.cmake
@@ -12,3 +12,8 @@ add_executable(main main.cpp)
target_link_libraries(main library)
install(TARGETS library ARCHIVE DESTINATION lib)
+
+include(CTest)
+add_test(NAME main
+ COMMAND main
+)
```https://gitlab.kitware.com/cmake/cmake/-/issues/24002Support for generating XCode scheme action property customLLDBInitFile2024-01-26T16:20:45-05:00iansusernameSupport for generating XCode scheme action property customLLDBInitFileIn XCode it's sometimes necessary to have a LLDB Init file to allow a customized debugging environment. e.g. default signal behavior is to breakpoint, but this is not always desirable, so can be customized in the file.
In the XCode GUI ...In XCode it's sometimes necessary to have a LLDB Init file to allow a customized debugging environment. e.g. default signal behavior is to breakpoint, but this is not always desirable, so can be customized in the file.
In the XCode GUI The way to specify an LLDB Init file is through the "Product->Scheme->Edit Scheme...->Info (Tab)->LLDB Init File (Field).
This modifies the <customLLDBInitFile> property of the selected scheme action.
It seems to be available for the TestAction and LaunchAction actions of each scheme
e.g. after setting the value for both actions to `$(SRCROOT)/LLDBInitFile`:
```
<Scheme>
<TestAction>...<customLLDBInitFile>$(SRCROOT)/LLDBInitFile</customLLDBInitFile>...</TestAction>
<LaunchAction>...<customLLDBInitFile>$(SRCROOT)/LLDBInitFile</customLLDBInitFile>...</LaunchAction>
```
It would be great if this property could be controlled in CMake XCode scheme generation, either for a specific target scheme, or globally for all target schemes.https://gitlab.kitware.com/cmake/cmake/-/issues/25557Documentation: Missing mention of the [variant=<Config>] syntax for [CMAKE_]_...2024-01-08T10:44:48-05:00Ilya KulakovDocumentation: Missing mention of the [variant=<Config>] syntax for [CMAKE_]_XCODE_ATTRIBUTE_<attribute> variables and properties.CMake allows to specify Xcode Configuration that a given Xcode attribute applies to, regardless whether set via a variable or property:
```cmake
set_target_properties(...
XCODE_ATTRIBUTE_LLVM_LTO "Monolithic"
XCODE_ATTRIBUTE_LLV...CMake allows to specify Xcode Configuration that a given Xcode attribute applies to, regardless whether set via a variable or property:
```cmake
set_target_properties(...
XCODE_ATTRIBUTE_LLVM_LTO "Monolithic"
XCODE_ATTRIBUTE_LLVM_LTO[variant=Debug] "Incremental"
)
```
will set the `LLVM_LTO` build setting to `Monolithic` for all Xcode configurations but Debug which will be set to `Incremental` instead.
Neither [`CMAKE_XCODE_ATTRIBUTE_<an-attribute>`](https://cmake.org/cmake/help/latest/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html) nor [`XCODE_ATTRIBUTE_<an-attribute>`](https://cmake.org/cmake/help/latest/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html) mentions that.
https://cmake.org/Bug/view.php?id=8179https://gitlab.kitware.com/cmake/cmake/-/issues/25538make test errors after build on Mac2023-12-30T07:09:02-05:00Benjamin Gmake test errors after build on MacHello, I built cmake on a Mac (Mojave/10.14;Xcode 11.4.1) as part of the development environment I am building and got 6 failures during "make test". To simplify I am grouping into issues I think related and share what will like be thre...Hello, I built cmake on a Mac (Mojave/10.14;Xcode 11.4.1) as part of the development environment I am building and got 6 failures during "make test". To simplify I am grouping into issues I think related and share what will like be three issues total one at a time.
The first relates to failures that come up in "Architecture" and "BuildDepends" tests from an assumption that the Xcode GUI is installed and therefore "xcodebuild" works. If only the command line tools are installed, xcodebuild fails with:
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
In the context this seems like a heavyweight assumption since it is only being used to determine if Xcode V.3 versus V.4+ is installed and then only to determine whether the host supports targeting ppc, i386, and/or x86_64. I would offer alternate code for both tests but not sure which way you want to go.
Does Cmake V.3.28+ support host platforms running Xcode 4 (circa 2011-2013, likely Mac OS X Snow Leopard or maybe Lion) or even Xcode 3 (circa 2007-2011, likely Snow Leopard)? If no to Xcode 3, then seems like testing for it as a way to see if ppc is an available target is a moot point. Otherwise if assuming Mac OS X 10.10 or later as a minimum host platform, one can assume Xcode 6 tools and options are available. Or depending on the goals here, perhaps better to just build tests programs for different targets to see which work/error rather than trying to track which version of Xcode does what or even that the user is using Apple tools rather than GCC or LLVM?
Either way, I also think now would be time to update these tests to consider host platform that target arm64 as well as x86_64.https://gitlab.kitware.com/cmake/cmake/-/issues/22924XCODE_EMBED_FRAMEWORKS chooses the wrong directory for targets in a subdirectory2023-12-15T16:59:46-05:00Mitchell WongXCODE_EMBED_FRAMEWORKS chooses the wrong directory for targets in a subdirectoryFor a project with the directory structure
root:
- subdir/
- CMakeLists.txt
- library.cpp
- CMakeLists.txt
- main.cpp
when setting `XCODE_EMBED_FRAMEWORKS` on the main target with the target created in the subdir, Xcode will complai...For a project with the directory structure
root:
- subdir/
- CMakeLists.txt
- library.cpp
- CMakeLists.txt
- main.cpp
when setting `XCODE_EMBED_FRAMEWORKS` on the main target with the target created in the subdir, Xcode will complain `error: <CMAKE BUILD DIR>/Debug/libsubdir-library.a: No such file or directory`. This is because the actual build path of `libsubdir-library` is `<CMAKE BUILD DIR>/subdir/Debug/libsubdir-library.a`
Tested on 3.22 RC3.
Example project attached:
[test-xcode-embed-frameworks.zip](/uploads/e61ed03c68992d83068be7141053b997/test-xcode-embed-frameworks.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/25487XCODE_EMBED_FRAMEWORKS does not support imported framework or xcframework tar...2023-12-15T00:32:26-05:00Craig ScottXCODE_EMBED_FRAMEWORKS does not support imported framework or xcframework targetsWhen using the Xcode generator, the `XCODE_EMBED_FRAMEWORKS` accepts targets or paths. You can create an imported target for a shared framework, and starting with CMake 3.28, an imported shared library target should be able to represent ...When using the Xcode generator, the `XCODE_EMBED_FRAMEWORKS` accepts targets or paths. You can create an imported target for a shared framework, and starting with CMake 3.28, an imported shared library target should be able to represent a XCFramework. One can successfully create such an imported target (framework or xcframework), but it generates an error if you set `XCODE_EMBED_FRAMEWORKS` to it. Here's a rough sketch of the problem:
```cmake
# An XCFramework I've built in a separate project. For this problem, this could be
# either a .framework or a .xcframework.
set(XPLATXCF_LIBRARY /path/to/xplatxcf.xcframework)
# Imported target to represent the XCFramework (should be valid starting with CMake 3.28)
add_library(xplatxcf SHARED IMPORTED GLOBAL)
set_target_properties(xplatxcf PROPERTIES
IMPORTED_LOCATION ${XPLATXCF_LIBRARY}
)
add_executable(XCApp ...)
set_target_properties(XCApp PROPERTIES
... # Many other properties
# Embedding by target fails
XCODE_EMBED_FRAMEWORKS xplatxcf
# Embedding by path works
#XCODE_EMBED_FRAMEWORKS ${XPLATXCF_LIBRARY}
XCODE_LINK_BUILD_PHASE_MODE "KNOWN_LOCATION"
)
target_link_libraries(XCApp PRIVATE xplatxcf)
```
If you set `XCODE_EMBED_FRAMEWORKS` to the `xplatxcf` target, CMake fails with the following error:
```
CMake Error: Can not find a target for xplatxcf
CMake Generate step failed. Build files cannot be regenerated correctly.
```
Setting it to the actual location of the framework or XCFramework and setting the `XCODE_LINK_BUILD_PHASE_MODE` to `KNOWN_LOCATION` generates no such error and I have an example iOS project which uses this successfully.https://gitlab.kitware.com/cmake/cmake/-/issues/25447Xcode, build-for-testing, test-without-building is broken since 3.25.02023-12-04T10:39:53-05:00Yauheni KhnykinXcode, build-for-testing, test-without-building is broken since 3.25.0Hi,
Xcode has feature to build packages for testing and then run tests on separate node, so it's handy to parallelise tests.
We use this feature with iOS, but it'a also reproducible with pure MacOS build:
Consider the following configura...Hi,
Xcode has feature to build packages for testing and then run tests on separate node, so it's handy to parallelise tests.
We use this feature with iOS, but it'a also reproducible with pure MacOS build:
Consider the following configuration:
```
project (XCtestRunBug Swift)
cmake_minimum_required(VERSION 3.23.1)
file(WRITE ${CMAKE_BINARY_DIR}/foo.swift "public func foo() {}")
file(WRITE ${CMAKE_BINARY_DIR}/foo_test.swift "func foo() {}")
add_library(demo SHARED ${CMAKE_BINARY_DIR}/foo.swift)
set_target_properties(demo PROPERTIES
FRAMEWORK TRUE
XCODE_ATTRIBUTE_DEFINES_MODULE YES
XCODE_GENERATE_SCHEME YES)
find_package (XCTest REQUIRED)
xctest_add_bundle (demo-test-bundle demo)
target_sources(demo-test-bundle PRIVATE ${CMAKE_BINARY_DIR}/foo_test.swift)
```
Then the following sequence of actions:
```
# Configure
cmake . -B build -GXcode
# Build for testing
xcodebuild -project build/XCtestRunBug.xcodeproj -configuration Debug -scheme demo build-for-testing
# Move prebuilt file to another place
mv build build2
# Test without building
xcodebuild -xctestrun build2/build/demo_macosx13.1-arm64.xctestrun -destination platform=macOS test-without-building
# Prior cmake 3.25.0 the file xctestrun was in different place
# xcodebuild -xctestrun build2/demo_macosx13.1-arm64.xctestrun -destination platform=macOS test-without-building
```
I expect that tests are run. It was like this in cmake 3.24.4, but in cmake 3.25.0 (actually starting with rc1) I see the following errors:
```
xcodebuild: error: Failed to build workspace XCtestRunBug with scheme demo.
Reason: Cannot test target “demo-test-bundle” on “My Mac”: Missing test product at /blah/cmake-xctestrun/build/Debug/demo-test-bundle.xctest
Reason: Cannot test target “demo-test-bundle” on “My Mac”: Missing test product at /blah/cmake-xctestrun/build/Debug/demo-test-bundle.xctest
```
I found that file `demo_macosx13.1-arm64.xctestrun` moved to different location (see above) and paths inside became absolute (while were relative to `__TESTROOT__`). For example in cmake 3.24.4:
```
<key>DependentProductPaths</key>
<array>
<string>__TESTROOT__/Debug/demo-test-bundle.xctest</string>
<string>__TESTROOT__/Debug/demo.framework</string>
```
in cmake 3.25.0:
```
<key>DependentProductPaths</key>
<array>
<string>/blah/cmake-xctestrun/build/Debug/demo-test-bundle.xctest</string>
<string>/blah/cmake-xctestrun/build/Debug/demo.framework</string>
```
So it definitely is looking in wrong place. Manual replacing `/blah/cmake-xctestrun` with `__TESTROOT__`. doesn't make any difference, so something else seems broken.https://gitlab.kitware.com/cmake/cmake/-/issues/23851Xcode: Configuring with '-DCMAKE_OSX_ARCHITECTURES=$(ARCHS_STANDARD)' fails ...2023-12-01T23:38:51-05:00alcroitoXcode: Configuring with '-DCMAKE_OSX_ARCHITECTURES=$(ARCHS_STANDARD)' fails to link object libraries into an executable```cmake
cmake_minimum_required(VERSION 3.16)
project(app LANGUAGES CXX)
set(source_my_obj_lib "${CMAKE_BINARY_DIR}/source_my_obj_lib.cpp")
file(GENERATE OUTPUT "${source_my_obj_lib}" CONTENT "void bar() {}")
add_library(actual_my_obj_l...```cmake
cmake_minimum_required(VERSION 3.16)
project(app LANGUAGES CXX)
set(source_my_obj_lib "${CMAKE_BINARY_DIR}/source_my_obj_lib.cpp")
file(GENERATE OUTPUT "${source_my_obj_lib}" CONTENT "void bar() {}")
add_library(actual_my_obj_lib OBJECT ${source_my_obj_lib})
set(app_cpp "${CMAKE_BINARY_DIR}/main.cpp")
file(GENERATE OUTPUT "${app_cpp}" CONTENT "int main() { return 0; }")
add_executable(app ${app_cpp})
target_link_libraries(app PRIVATE "$<TARGET_OBJECTS:actual_my_obj_lib>")
```
When configuring the project above with
```
cmake -GXcode .. '-DCMAKE_OSX_ARCHITECTURES=$(ARCHS_STANDARD)'
```
the application linking step will fail with:
```
$ xcodebuild
...
Ld /build/app.build/Debug/app.build/Objects-normal/arm64/Binary/app normal arm64 (in target 'app' from project 'app')
cd
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -target arm64-apple-macos10.15 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -L/build/Debug -F/build/Debug -filelist /build/app.build/Debug/app.build/Objects-normal/arm64/app.LinkFileList -Xlinker -object_path_lto -Xlinker /build/app.build/Debug/app.build/Objects-normal/arm64/app_lto.o -Xlinker -no_deduplicate -Wl,-search_paths_first -Wl,-headerpad_max_install_names /build/app.build/Debug/actual_my_obj_lib.build/Objects-normal/arm64 x86_64/source_my_obj_lib.o -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /build/app.build/Debug/app.build/Objects-normal/arm64/app_dependency_info.dat -o /build/app.build/Debug/app.build/Objects-normal/arm64/Binary/app
clang: error: no such file or directory: 'x86_64/source_my_obj_lib.o'
```
Note the space in `/build/app.build/Debug/actual_my_obj_lib.build/Objects-normal/arm64 x86_64/source_my_obj_lib.o`
I believe that happens here https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmGlobalXCodeGenerator.cxx#L4499
because `$(ARCHS_STANDARD)` is interpreted as a single architecture value by CMake, and then it expands into a space separated list.
The value of `ARCHS_STANDARD` can be seen by running
```
$ xcodebuild -showBuildSettings | grep ARCHS_STANDARD
ARCHS_STANDARD = arm64 x86_64
```
When configuring with
```
cmake -GXcode .. '-DCMAKE_OSX_ARCHITECTURES=x86_64;arm64'
```
the executable links successfully, because the object files are referred to using `$(CURRENT_ARCH)` instead.https://gitlab.kitware.com/cmake/cmake/-/issues/23442Xcode: Using the standard architectures2023-11-10T02:40:30-05:00Nick BrookXcode: Using the standard architecturesI use CMake to generate a Xcode project for a library. I use the library in an iOS App, which uses the standard architectures when archiving (arm64, arm7). CMake generates the library with only the host architecture by default, specified...I use CMake to generate a Xcode project for a library. I use the library in an iOS App, which uses the standard architectures when archiving (arm64, arm7). CMake generates the library with only the host architecture by default, specified on the target (not project). Previously I used `set(CMAKE_XCODE_ATTRIBUTE_ARCHS "$(ARCHS_STANDARD)")` to force the standard archs, but now this is overridden on the target in recent CMake versions. This means I have to use `set_target_properties(${target} PROPERTIES XCODE_ATTRIBUTE_ARCHS "\$(ARCHS_STANDARD)")` on all targets that I want to use standard architectures. Does CMake really need to set a default value for XCODE_ATTRIBUTE_ARCHS on each target? Can this default value be overridden?https://gitlab.kitware.com/cmake/cmake/-/issues/25269Swift: Add option to set default cxx-interoperability-mode2023-10-25T17:22:23-04:00Andrew KasterSwift: Add option to set default cxx-interoperability-mode<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
With Swift 5.9/Xcode 15 they have added more C++ Interop features.
The `-enable-experimental-cxx-interop` flag has been replaced with `-cxx-interoperability-mode=default` or `-cxx-interoperability-mode=off`
> $ swiftc --help | grep interop
> -cxx-interoperability-mode=<value>
> Enables C++ interoperability; pass 'default' to enable or 'off' to disable
However, setting this flag on a swift target has no impact on a generated Xcode project. The project should have the `C++ and Objective C Interoperability` setting set to "C++/Objective C++" rather than the default "C/Objective C". Turns out the default mode is not "default" but "off" :thinking:.
![270131386-258334a0-3f4c-44cf-8587-cdf3a743438e](/uploads/0510f93b12de68e8705bfadd8e57b616/270131386-258334a0-3f4c-44cf-8587-cdf3a743438e.png)
Should there be a global setting to set this flag on the project builtin to CMake? Or is it my responsibility to set the Xcode property on my swift target manually?
Here's an example that uses the feature that I forked and updated for Xcode 15.
https://github.com/ADKaster/swift-cmake-examples/tree/xcode-15/Interop
Note that I used this example in an upstream bug report here https://github.com/apple/swift/issues/68726, pointing out that the C++20 char8_t struct member is dropped on the floor when used.https://gitlab.kitware.com/cmake/cmake/-/issues/23675Xcode: Unable to code sign when embeding a macOS framework inside two differe...2023-10-25T02:31:32-04:00Jens CarlXcode: Unable to code sign when embeding a macOS framework inside two different bundlesI have project where I create a macOS framework and then embed the framework inside two different executable/bundles with code signing enabled. Configuring and generating is working with command `cmake -G Xcode ..`. But when I build the ...I have project where I create a macOS framework and then embed the framework inside two different executable/bundles with code signing enabled. Configuring and generating is working with command `cmake -G Xcode ..`. But when I build the project with
`cmake --build . --config Debug` it's failing with error:
```
/usr/bin/codesign --force --sign XXXXXXXXXXXXXXXXX -o runtime --entitlements /Users/jcarl/devel/CMake_Embed_Sign_Framework/build/exe1/EmbedFrameworkTwice.build/Debug/exe1.build/Exe1.app.xcent --timestamp\=none /Users/jcarl/devel/CMake_Embed_
Sign_Framework/build/exe1/Debug/Exe1.app
/Users/jcarl/devel/CMake_Embed_Sign_Framework/build/exe1/Debug/Exe1.app: code object is not signed at all In subcomponent: /Users/jcarl/devel/CMake_Embed_Sign_Framework/build/exe1/Debug/Exe1.app/Contents/Frameworks/Fwk.framework
Command CodeSign failed with a nonzero exit code
```
It's randomly failing with one of my bundles.
I attached a project where you can reproduce the error. **NOTE**: A Apple Development Team ID has to be set in the main CMakeLists.txt.
I also dug a little bit into the generated Xcode project file to understand what maybe going wrong.
In the section `PBXBuildFile` I see the framework
```
3686758ACF9F40438DA851F4 = {isa = PBXBuildFile; fileRef = 7B19B44200274907B37896E8 /* fwk */; settings = {ATTRIBUTES = (RemoveHeadersOnCopy,CodeSignOnCopy); }; };
```
which then referenced twice in the section `PBXCopyFilesBuildPhase`
```
926C40A995274995A5E04088 /* Embed Frameworks */ = {
isa = PBXCopyFilesBuildPhase;
buildActionMask = 2147483647;
dstPath = "";
dstSubfolderSpec = 10;
files = (
3686758ACF9F40438DA851F4,
);
name = "Embed Frameworks";
runOnlyForDeploymentPostprocessing = 0;
};
F06C43EF489147F8BA027FC0 /* Embed Frameworks */ = {
isa = PBXCopyFilesBuildPhase;
buildActionMask = 2147483647;
dstPath = "";
dstSubfolderSpec = 10;
files = (
3686758ACF9F40438DA851F4,
);
name = "Embed Frameworks";
runOnlyForDeploymentPostprocessing = 0;
};
```
From my limited understand of Xcode it seems that Xcode gets upset if a PBXBuildFile referenced by two different PBXCopyFilesBuildPhase.
[CMakeEmbedSignFramework.zip](/uploads/b24d69b0673ccc68d59edff74f79fe82/CMakeEmbedSignFramework.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/25259Xcode generator: schemes not used for cmake --build, schemes missing from ALL...2023-09-20T08:50:03-04:00Craig ScottXcode generator: schemes not used for cmake --build, schemes missing from ALL_BUILDThe `CMAKE_XCODE_GENERATE_SCHEME` variable can be used to enable scheme generation when using the Xcode generator. That will initialise the `XCODE_GENERATE_SCHEME` property of each target. A similar pattern follows for the various `CMAKE...The `CMAKE_XCODE_GENERATE_SCHEME` variable can be used to enable scheme generation when using the Xcode generator. That will initialise the `XCODE_GENERATE_SCHEME` property of each target. A similar pattern follows for the various `CMAKE_XCODE_SCHEME_...` variables and their associated `XCODE_SCHEME_...` target properties.
To enable sanitisers, you would typically set the variables to apply them across the whole build. That means you'd set something like the following:
```cmake
cmake -G Xcode -S . -B build-xcode \
-DCMAKE_XCODE_GENERATE_SCHEME=TRUE \
-DCMAKE_XCODE_SCHEME_ADDRESS_SANITIZER=TRUE \
-DCMAKE_XCODE_SCHEME_UNDEFINED_BEHAVIOR_SANITIZER=TRUE
```
But if you then build using `cmake --build`, it doesn't use the generated schemes and sanitisers are not enabled. As a workaround, you can invoke `xcodebuild` directly, asking for a scheme rather than a target to be built. That command line would look something like this:
```
xcodebuild -project sanitizers.xcodeproj build -scheme SomeTarget -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
```
This does build `SomeTarget` with sanitisers enabled. However, if you want to build the whole project, this workaround fails. The generated `ALL_BUILD` target doesn't get the scheme settings applied, meaning it doesn't have any of the sanitisers enabled. If it did, then the following would work:
```
xcodebuild -project sanitizers.xcodeproj build -scheme ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
```
* BUG PART A: `cmake --build` should prefer to invoke `xcodebuild -scheme` rather than `xcodebuild -target` if a scheme exists for the requested target (or `ALL_BUILD` if no target was explicitly requested).
* BUG PART B: `XCODE_SCHEME_...` settings should also be applied to the `ALL_BUILD` scheme (at least, where possible and where the scheme setting could potentially change how things are built).
An alternative change for PART A might be to support `cmake --build ... --scheme ...` as an alternative to `cmake --build ... --target ...`. At least then the developer can explicitly state that they want the scheme rather than the target. It would probably be better if `cmake --build` could work this out for itself though.https://gitlab.kitware.com/cmake/cmake/-/issues/16533Xcode Generator: Custom Project Name2023-09-18T06:23:18-04:00AlexDenisovXcode Generator: Custom Project NameHi there.
I'd like to bring a small feature: custom name for a Xcode project.
Here is my motivation: on my machine I have few copies of LLVM, for each of them I have separate Xcode project.
The problem appears when I switch between di...Hi there.
I'd like to bring a small feature: custom name for a Xcode project.
Here is my motivation: on my machine I have few copies of LLVM, for each of them I have separate Xcode project.
The problem appears when I switch between different Xcode projects, or when I want to open another project: there is almost no way to determine which copy I'm working with. The only way to differentiate things now is to remember the target I worked with in each project.
But it's so annoying, error-prone, and counter-productive so I'd like CMake to generate me a project with a different, custom name.
i.e.:
```
cmake -G Xcode ~/Projects/LLVM/src
cmake -G Xcode -DCMAKE_XCODE_PROJECT_NAME=Mull ~/Projects/Mull/src
cmake -G Xcode -DCMAKE_XCODE_PROJECT_NAME=IRTests ~/Projects/Mull/Lab/src
```
where the commands will spit out xcode projects as the following: `LLVM.xcodeproj`, `Mull.xcodeproj`, `IRTests.xcodeproj`.
So far I looked into `cmGlobalXCodeGenerator` and found that this change can be done easily (see the patch below).
Now I have several questions:
1. Can such a feature be accepted into upstream?
2. What is the recommended way to write tests for this feature?
3. What else needs to be done to make this work besides the change below?
I will also appreciate any reference to more detailed contributing guidelines, if there are any.
P.S. the patch:
```diff
diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx
index 736aa91..4fea196 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3264,9 +3264,16 @@ void cmGlobalXCodeGenerator::OutputXCodeProject(
if (!this->CreateXCodeObjects(root, generators)) {
return;
}
+
+ const char *customProjectName = this->CurrentMakefile->GetDefinition("CMAKE_XCODE_PROJECT_NAME");
+ std::string projectName = root->GetProjectName();
+ if (customProjectName) {
+ projectName = std::string(customProjectName);
+ }
+
std::string xcodeDir = root->GetCurrentBinaryDirectory();
xcodeDir += "/";
- xcodeDir += root->GetProjectName();
+ xcodeDir += projectName;
xcodeDir += ".xcode";
if (this->XcodeVersion > 20) {
xcodeDir += "proj";
```Gregor JasnyGregor Jasny