openframeworks
XCode OF compiled $(ARCHS) instead of $(ARCHS_STANDARD)
In my tests it is building OK for Apple Silicon, Intel or Universal.
hopefully closes https://github.com/openframeworks/openFrameworks/issues/7043
Thanks! I'll test this out tomorrow and see if it does it all correctly.
My thought was to set ONLY_ACTIVE_ARCH to YES for Debug and Release in both the OF Xcode project and the template project - but then make sure we were passing through the My Mac vs Any Mac setting to the OF Xcode project based on what people were setting in their app project. When Any Mac is set the active architecture then becomes both x86_64 and arm64.
So if someone set Any Mac in emptyExample.xcodeproj it would set it in OF.xcodeproj and produce a universal emptyExample.app.
@dimitre thanks for the reminder!
Thinking about this more I think all we should do to address this is to set Build Active Architecture Only to Yes for Release builds in the project template ( leaving the OF project as is ).
This allows people to compile examples faster and when they want to share across platforms they can use the 'Any Mac' target.
OF doesn't get recompiled often and so I think it is simpler to leave it as a universal lib.
One other thing that would be great is if the new json formatted template could be prettified or at least have line breaks so it doesn't look like this in Git. 🙂
Nice' I've sent a PR for json format. About your latest suggestion I think things are already working this way in latest. at least I can see the difference in universal binary size vs. Rosetta or M1.
But one thing I liked a lot in your previous suggestion (compile the core in actual architecture only) is it is faster to work on the core, test PRs, probably github actions too. So I'll be using that in my setup :)
@dimitre ahh - awesome didn't think it was already working like that.
Yeah, I think I also backtracked a bit on the idea of ARCHS based on thinking for CI at least we do want build the core Universal as we need to test both architectures. Then thinking that for most users it will compile once for Debug and Release and then as long as the examples and projects are native only, you are not doing extra compiles for daily projects.
But yeah for people working on OF itself - def is nice to disable other Archs.
I think the can close this now - if the current behavior is Debug and Release only building active archs, that should be an improvement from before!
Thanks @dimitre for looking into this!
Hello @ofTheo I still want to discuss this one some more lol In fact I love the idea of only building the core in the actual architecture. I mean, in my usage I deliver a lot of universal software, but 99% of the time is development, so it is one architecture only, most of the time. Even for CI I think most of the testing is done on x86_64
@dimitre sure thing!
I think the main thing to do then would be to figure out how to pass the My Mac / Any Mac parameter through to the openFrameworksCompiled.xcodeProj
similar to how we are doing for C++17:
"shellScript": "xcodebuild -project \"$OF_PATH/libs/openFrameworksCompiled/project/osx/openFrameworksLib.xcodeproj\" -target openFrameworks -configuration \"${CONFIGURATION}\" CLANG_CXX_LANGUAGE_STANDARD=$CLANG_CXX_LANGUAGE_STANDARD MACOSX_DEPLOYMENT_TARGET=$MACOSX_DEPLOYMENT_TARGET\n",
That way openFrameworksCompiled could be set to "Active Architecture Only" and the main project would then pass through the target ( whether Intel or Arm My Mac or both Any Mac ).
The only downside to the CI not compiling OF for both is that we might miss errors that exist just on one platform ( which has come up in the past, like missing symbols or api calls ). But for the speed we'd gain maybe its okay?
Yeah. don't you think it will automatically compile the core for the selected architectures automatically if binaries for the platform are not present? I can test this here.
I think api calls are really standarized if we compile for different archs, lets say m1 and intel (which is the case here in this PR not different platforms) . I've only seen differences when dealing with intrinsics when M1 started, but even then on complex addons like ofxNDI, I dont think the core itself has any of this complexities