openframeworks
macOS vs osx / bleeding and standard libraries ideas
I've noticed recently the bleeding libs are the go to version in latest OF source code, with changes here
libs/openFrameworksCompiled/project/osx/openFrameworksLib.xcodeproj/project.pbxproj
As it is expected to break ongoing projects my suggestion is we separate completely both ways of working using a separate "platform" in projectGenerator, pointing to libs/openFrameworksCompiled/project/macOS/
so it will be easier to work with classic libraries download_libs.sh and testing in parallel all bleeding until it is a smooth transition.
What do you think? @danoli3 @ofTheo ?
we can rename ./scripts/osx/download_latest_libs.sh -> ./scripts/macOs/download_libs.sh
and do the same for project and template.
I think this have two advantages, one we have the option of still using "osx" if some edge case appear
and the second it begins the name transition from osx to macOS without breaking anything
as a git-based user, there is definitely a need for more clarity around this — as seen in #8039 yesterday I went in for a minor tweak on a fairly recent git-based project on a machine that had an older git tree, got a compile error and just automatically went for a git pull; error still happens, went for download_libs and saw the options got a bit confused; tried things and "bricked" the tree. the fix is not so hard once macos is excluded and you nuke the libs between tries, but it's clearly not a fluid experience... and for a while your project does not compile, which creates doubt and stress.
it reminds of a discussion (can't locate it) about being able to have different sets of libs within the same OF folder (the typical case being macOS + iOS); I guess similarly it would make sense here to have the osx and macos libs not overlapping in the filesystem? otherwise it's not so simple to toggle between "platforms"...
also it was the recent idea to promote git/nightlies as the "supported OF version" -- if that is still the case (I think it is, unless the rate of release can be significantly raised) this reveals there is a need an extra layer of staging/testing before pushing a "delivered" git version. I don't mind hitting such blocks as I'm fairly at ease moving things around but I can imagine the general debacle if most Mac users were on git and put themselves in non-working tree by mismatching osx and macOS...
Pretty much the idea is for macOS project, which I forgot to fix up recently, but is a mega project capable of all outputs. The template needs to be linked up in projectGenerator still todo
for now lets leave osx download and project targeting still the osx.
I think though this raises some good points I think a lot can be fixed with a working projectGenerator Going to dive into fixing the projectGenerator
Looking at this again as projectGenerator fixes almost complete now.
macOS Super Mega project needs some work, but once I merge in the Metal ANGLE stuff, hooley Dooley
I think its maybe best to just put the OSX xcframework download into the /macos/ folder as the macOS super mega also includes the MacOS slice. This way we work on the conforming and fixes a lot of issues with running from iOS or macOS slices in the future
Only thing to consider is the xcframeworks plist which would just need to verify if an existing mega one, and just not deploy if so else would overrwite the plist for all the platforms
@dimitre in the make files, when you did the osx-macos change over stuff, was there much there we need to consider
the idea of separating osx folder for classic libs and projectGenerator template is this way we can keep work projects in a more conservative and tested libs structure until macOS / xcframeworks gets working 100%
It is getting confusing for me to fullfill all requirements to have an up to date version of OF working