CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-14T13:02:39-04:00https://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/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/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/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/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/24832Xcode: CMake fails only first time with a syntax error but other tries succeed2023-04-25T15:08:15-04:00Orkun TokdemirXcode: CMake fails only first time with a syntax error but other tries succeed<!--
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/
-->
I've noticed that there is a problem in `cmake` cache or timestamps when I select `Xcode` as the generator.
Example:
`CMakelists.txt`
```cmake
cmake_minimum_required(VERSION 3.20)
project(macos_app)
add_executable(macos_app main.cpp)
```
`main.cpp`
```c++
int main()
{
return 0;
}
```
`Build command`
```sh
rm -rf build && cmake -S . -B build/ -G Xcode -DCMAKE_CONFIGURATION_TYPES="Debug;Release" && cmake --build build/ --verbose
```
When the above command is run, it works successfully.
If I add a syntax error like the one below and run the below command it will fail.
```cmake
cmake_minimum_required(VERSION 3.20)
project(macos_app)
add_executable(macos_app main.cpp)
asdasd
```
`command`
```sh
cmake --build build
```
But if I rerun the above command, it will succeed and ignore the syntax error.
Could you please check it?
Thank you in advance.
```
Xcode version: Version 14.3 (14E222b)
CMake version: cmake version 3.25.1
```https://gitlab.kitware.com/cmake/cmake/-/issues/24831Xcode: `"Based on dependency analysis" is unchecked` warning2023-05-02T03:47:14-04:00Orkun TokdemirXcode: `"Based on dependency analysis" is unchecked` warning<!--
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/
-->
I've noticed that `cmake` returns warnings when `Xcode` is selected as the generator.
Example:
`CMakelists.txt`
```cmake
cmake_minimum_required(VERSION 3.20)
project(macos_app)
add_executable(macos_app main.cpp)
```
`main.cpp`
```c++
int main()
{
return 0;
}
```
`Build command`
```sh
rm -rf build && cmake -S . -B build/ -G Xcode -DCMAKE_CONFIGURATION_TYPES="Debug;Release" && cmake --build build/ --verbose
```
When the above command is run, the below warnings can be seen in the output.
```sh
note: Run script build phase 'Generate CMakeFiles/ZERO_CHECK' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'ZERO_CHECK' from project 'macos_app')
note: Run script build phase 'Generate CMakeFiles/ALL_BUILD' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'ALL_BUILD' from project 'macos_app')
```
When I further investigated the root cause of it, I found that `cmake` sets the `alwaysOutOfDate` flag in `*.pbxproj` [here](https://gitlab.kitware.com/cmake/cmake/-/commit/8d5f4c4db93959f77dc8fb185e4630df4ec26d98#2f50f576cb9c2864f59b6d6ae2961385ef470cb2_1753_1917) and [here](https://gitlab.kitware.com/cmake/cmake/-/commit/8d5f4c4db93959f77dc8fb185e4630df4ec26d98#2f50f576cb9c2864f59b6d6ae2961385ef470cb2_1753_1966).
It seems like `cmake` uses [Run script build phase](https://developer.apple.com/documentation/xcode/running-custom-scripts-during-a-build?changes=_8)
to check whether dependencies are modified or not.
Is there a way to disable those warnings? or remove them completely without changing the workflow of `cmake` with `Xcode`?
```sh
Xcode version: Version 14.3 (14E222b)
CMake version: cmake version 3.25.1
```https://gitlab.kitware.com/cmake/cmake/-/issues/24676Xcode: cmake does not correctly enable parallelised builds for command-line b...2023-04-26T14:08:40-04:00Patrick HeyerXcode: cmake does not correctly enable parallelised builds for command-line buildsThe Xcode generator correctly sets `BuildIndependentTargetsInParallel` to `YES`, but it seems that the `objectVersion` parameter needs to be increased for this to correctly take effect:
* The current value is `46`: https://gitlab.kitwar...The Xcode generator correctly sets `BuildIndependentTargetsInParallel` to `YES`, but it seems that the `objectVersion` parameter needs to be increased for this to correctly take effect:
* The current value is `46`: https://gitlab.kitware.com/cmake/cmake/-/blob/v3.17.0/Source/cmGlobalXCodeGenerator.cxx#L3489
* Xcode 14.3 uses a value of `54`.
This setting needs to be set to a value of at least `53` to take effect in Xcode 14.3.
I cross-checked this with Xcode 14.2 on macOS 12.6.4 with the same results.https://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/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/24379Xcode projects generated by CMake cannot build documentation2023-02-20T08:32:17-05:00Nenad Miksa (DoDo)Xcode projects generated by CMake cannot build documentationXcode 14 introduced a new documentation compiler that can automatically build the documentation from the code.
However, if Xcode project is generated by CMake, and there is at least one folder in `target_include_directories` that has th...Xcode 14 introduced a new documentation compiler that can automatically build the documentation from the code.
However, if Xcode project is generated by CMake, and there is at least one folder in `target_include_directories` that has the same name as the framework's `PRODUCT_NAME`, and contains a public header, then the documentation compiler fails as it sees duplicate definitions of classes - one in the public header of the built framework, and another in the original folder.
This does not seem to bother the hand-crafted Xcode project with the same files and build settings.
I've attached a minimal reproducible sample: [test.zip](/uploads/62ba9568d685f15fc58335090590521c/test.zip). You can reproduce the issue by:
- unzipping the provided file
- create an empty folder and navigate to it
- issue `cmake -GXcode -DCMAKE_SYSTEM_NAME=iOS /path/to/unzipped/folder`
- open the generated Xcode project and select `test` scheme
- Select `Product->Build Documentation` (or press ctrl+cmd+shift+D)
The documentation should be built, instead, the documentation compiler fails with the error `duplicate interface definition for class 'MyTest'`.
Removing `target_include_directories` from the provided `CMakeLists.txt` seems to resolve the issue, but we cannot do so in production.
I'm using CMake v3.25.2 on M1 Mac.https://gitlab.kitware.com/cmake/cmake/-/issues/24328Xcode: Libraries created with NO_SONAME set to true still get cmake_symlink_l...2023-01-17T10:25:23-05:00Patrick HeyerXcode: Libraries created with NO_SONAME set to true still get cmake_symlink_library POST_BUILD actionWhen setting the `NO_SONAME` property to `TRUE` on a shared library target, no versioned symlinks are _actually_ generated, however the "CMake Post Build Rules" in an Xcode target still contain the corresponding calls:
```
if test "$CON...When setting the `NO_SONAME` property to `TRUE` on a shared library target, no versioned symlinks are _actually_ generated, however the "CMake Post Build Rules" in an Xcode target still contain the corresponding calls:
```
if test "$CONFIGURATION" = "Debug"; then :
cd <BINARY_DIR>
/opt/homebrew/Cellar/cmake/3.25.1/bin/cmake -E cmake_symlink_library <BINARY_DIR>/Debug/my_lib.dylib <BINARY_DIR>/Debug/my_lib.dylib <BINARY_DIR>/Debug/my_lib.dylib
fi
[...]
```
Fortunately this call does not seem to generate any symlinks or overwrite the original library file, I would expect CMake to omit the entire step when `NO_SONAME` is enabled however.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/24179Xcode: CMake adds same file multiple times2022-11-21T11:21:12-05:00Mikko SivulainenXcode: CMake adds same file multiple timesThe project has multiple targets (for example: macos, ios). Some sources are shared between the targets.
When CMake creates XCode project, it creates separate fileRef for common sources. This causes problems with XCode. For example, auto...The project has multiple targets (for example: macos, ios). Some sources are shared between the targets.
When CMake creates XCode project, it creates separate fileRef for common sources. This causes problems with XCode. For example, autocomplete does not work.
XCode project should only contain one fileRef per file, and multiple PBXBuildFile point to this single fileRef.
`cmGlobalXCodeGenerator::CreateXCodeFileReferenceFromPath` has a map that keeps track of what fileRefs have been created, using the key calculated by
`cmGlobalXCodeGenerator::GetGroupMapKeyFromPath`, but the latter creates the key per-target, not per-project.
If we change GetGroupMapKeyFromPath:
```
static std::string GetGroupMapKeyFromPath(cmGeneratorTarget* target,
const std::string& fullpath)
{
- std::string key(target->GetName());
- key += "-";
- key += fullpath;
- return key;
+ return fullpath;
}
```
We get the wanted behaviour, except empty groups are created under the targets. The source tree should also be per-project, not per-target.https://gitlab.kitware.com/cmake/cmake/-/issues/24161Xcode: TARGET_FILE, TARGET_BUNDLE_DIR, incorrect in POST_BUILD when using CMA...2022-11-14T11:53:57-05:00ChristopheXcode: TARGET_FILE, TARGET_BUNDLE_DIR, incorrect in POST_BUILD when using CMAKE_SYSTEM_NAME=iOSThe generator expressions $<TARGET_FILE:tgt> and $<TARGET_BUNDLE_DIR:tgt> return an incorrect path when used with cross compilation to iOS, when used as a POST_BUILD event.
This issue is very similar than https://gitlab.kitware.com/cmake...The generator expressions $<TARGET_FILE:tgt> and $<TARGET_BUNDLE_DIR:tgt> return an incorrect path when used with cross compilation to iOS, when used as a POST_BUILD event.
This issue is very similar than https://gitlab.kitware.com/cmake/cmake/-/issues/20938 yet very different result.
Take the following very simple CMake file
```cmake
cmake_minimum_required(VERSION 3.24)
project(Test LANGUAGES CXX VERSION 1.0.0.1)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED "NO")
add_executable(Test MACOSX_BUNDLE test.cpp)
add_custom_command(
TARGET Test
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E echo "############ Target file: $<TARGET_FILE:Test>"
COMMAND ${CMAKE_COMMAND} -E echo "############ Target bundle dir: $<TARGET_BUNDLE_DIR:Test>"
VERBATIM
)
```
### No cross-compilation
* Generate the solution like this: `cmake -H. -B_build -GXcode`
* Go to _build and run `cmake --build .`
* The output will correctly give:
* The full path to the file: `/.../_build/Debug/Test.app/test`
* The full path to the bundle: `/.../_build/Debug/Test.app`
### With iOS cross-compilation
* Generate the solution with iOS cross-compilation: `cmake -H. -B_build -GXcode -DCMAKE_SYSTEM_NAME=iOS`
* Go to _build and run `cmake --build `
* The output will give paths containing an unexpanded variable:
* File: `/.../_build/Debug${EFFECTIVE_PLATFORM_NAME}/Test.app/test`
* Bundle: `/.../_build/Debug${EFFECTIVE_PLATFORM_NAME}/Test.app`
All commands that rely on the generation expression TARGET_NAME or TARGET_BUNDLE_DIR thus fail to find the binary (like copy_directory or such).
(I think it's best to keep both my reported issues as the use cases are different, maybe it's possible to link/relate them or something equivalent)https://gitlab.kitware.com/cmake/cmake/-/issues/24091Xcode: CMAKE_CXX_COMPILER is ignored thus unable compile with different compi...2022-11-08T19:36:27-05:00Jason JuangXcode: CMAKE_CXX_COMPILER is ignored thus unable compile with different compilersPlease below minimal example:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.20)
project(sample)
add_executable(macos-sample main.cpp)
add_subdirectory(ios)
```
ios/CMakeLists.txt
```
set(CMAKE_CXX_COMPILER <path-to-ios-compiler>)
a...Please below minimal example:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.20)
project(sample)
add_executable(macos-sample main.cpp)
add_subdirectory(ios)
```
ios/CMakeLists.txt
```
set(CMAKE_CXX_COMPILER <path-to-ios-compiler>)
add_executable(ios-sample ../main.cpp)
```
This minimal example works perfectly if I generate a `make` project, (e.g. `cmake ..`) the `macos-sample` target is compiled with the macos compiler, and the `ios-sample` target is compiled with the ios compiler. However, if I generate a `xcode` project, (e.g. `cmake -G Xcode ..`), both the `macos-sample` target and the `ios-sample` target are compiled with the macos compiler. After further trial and error, I discovered that Xcode project seems to decide which compiler to use based on `CMAKE_OSX_SYSROOT`. However, the problem with `CMAKE_OSX_SYSROOT` is that setting it seem to only work if it's being set on the head CMakeLists.txt, meaning the below:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.20)
project(sample)
set(CMAKE_OSX_SYSROOT <path-to-ios-sdk>)
add_executable(macos-sample main.cpp)
add_subdirectory(ios)
```
ios/CMakeLists.txt
```
add_executable(ios-sample ../main.cpp)
```
both the `macos-sample` target and the `ios-sample` target are compiled with the ios compiler, but the below:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.20)
project(sample)
add_executable(macos-sample main.cpp)
add_subdirectory(ios)
```
ios/CMakeLists.txt
```
set(CMAKE_OSX_SYSROOT <path-to-ios-sdk>)
add_executable(ios-sample ../main.cpp)
```
both the `macos-sample` target and the `ios-sample` target are still compiled with the macos compiler. Can we fix Xcode so that it can recognize `CMAKE_CXX_COMPILER` just like `make` so that it's possible to compile the `macos-sample` target with macos compiler and compile the `ios-sample` target with ios compiler on Xcode?https://gitlab.kitware.com/cmake/cmake/-/issues/24079Xcode generator duplicates .o sources in .a static libraries2022-10-28T19:55:10-04:00Jeremy Maitin-ShepardXcode generator duplicates .o sources in .a static librariesCMakeLists.txt:
```
cmake_minimum_required(VERSION 3.24)
project(cmake_obj_test)
add_library(a empty.c src.o)
```
src.c:
```
void foo() {}
```
empty.c: (empty file)
Manually run:
```
clang -c -o src.o src.c
```
When the Xcode gen...CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.24)
project(cmake_obj_test)
add_library(a empty.c src.o)
```
src.c:
```
void foo() {}
```
empty.c: (empty file)
Manually run:
```
clang -c -o src.o src.c
```
When the Xcode generator is used, the resultant xcode project specifies `src.o` both in the source list and frameworks list for `a`. Consequently, `liba.a` ends up with two copies of `src.o`. Normally this goes unnoticed, but if the library is linked using WHOLE_ARCHIVE then it leads to a duplicate symbol error.