Until Cmake 3.29.6 this still worked fine. I’m using Xcode 15.1.
Now it seems the $(ARCHS_STANDARD) (which is resolved by Xcode) can no longer be used because of some “consistency check” that probably happens before this variable is resolved.
This is the commit that causes a FATAL_ERROR
The C compiler targets architectures:
"x86_64;arm64"
but CMAKE_OSX_ARCHITECTURES is
"$(ARCHS_STANDARD)"
Is this a newly-introduced Cmake bug? Or is my way of using $(ARCHS_STANDARD) not proper or supported anymore?
If I set it explicitly to set(CMAKE_OSX_ARCHITECTURES "x86_64;arm64" CACHE STRING ""), everything works as expected.
$(ARCHS_STANDARD) is a variable defined by Xcode, not an enviroment variable.
with this set(CMAKE_OSX_ARCHITECTURES $(ARCHS_STANDARD) CACHE STRING "") I’m assigning the literal string $(ARCHS_STANDARD) to CMAKE_OSX_ARCHITECTURES. Xcode will later resolve $(ARCHS_STANDARD) to e.g. “arm64 x86_64”
That is not the problem – CMakeCache.txt shows the correct entry: CMAKE_OSX_ARCHITECTURES:STRING=$(ARCHS_STANDARD)
The problem is that, since Cmake 3.30, Cmake will abort because of some ‘consistency check’ because it cannot resolve $(ARCHS_STANDARD) (which is obvious).
If you are suggesting “pre-resolving” $(ARCHS_STANDARD) e.g. with xcodebuild -showBuildSettings | grep ARCHS_STANDARD and saving it an environment variable and then using that within Cmake – yes, that would work, I guess.
But I don’t get why this should be necessary - the “literal string” method has worked with Cmake for years (decades).