-
Notifications
You must be signed in to change notification settings - Fork 758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mac OS 10.9 SDK compatibility #994
Conversation
- detect Mac OS 10.9 SDK - set -DMACOS_10_9 flag and MACOS_10_9 variable - use accelerate toolkit instead of vecKit - langsource/GC: fix header path
YYYYESSSS!
/* Joshua D. Parmenter “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono |
adding conditionals for individual osx versions is a bad idea in terms of long-term maintenance. |
Re tim's comment, maybe a slight tweak so that the "Accelerate" stuff is default, and the "vecLib" stuff (i.e. the legacy version) comes in for a flag such as MACOS_BEFORE_10_9...? That would presumably make it work correctly for 10.10. (Though the api will have changed again by then :) |
i'd not spend too much time on older osx versions/frameworks: afaict apple's policy is to keep source compatibility for 3 osx versions. veclib has been deprecated in favor of accelerate some time ago, and at one point it had been removed. so i'd remove all references to veclib now. of course there is the 'just in case' argument that someone will want to compile on 10.4 or 10.5 or 10.6, though people will run into other toolchain issues. and tbo trying to keep the code compatible with all of apple's API changes is a wonderful way to waste developer time. side note: apple's current dev tools only provide the sdks for 10.8 and 10.9. side note 2: sdk != minimum os version |
- don't try to detect 10.9 SDK as 10.10 will come some day - vecLib is deprecated since 10.7 SDK
re Dan: Changed it to be the default and an option instead of a detection thingy. Probably should be actually tested against a 10.7 SDK, don't have one. re Tim: I'd try to keep it compiling on 10.6 at least, as I think that a lot of people still use it and will continue using it. Also you'd need someone to compile it for you if you'd want to have libscsynth or some other special wishes on 10.6... But I see your point. |
Thanks, looks better to me - but my opinion is not so important as the actual Mac building people. |
sc/master won't compile for 10.6 anymore. setting a minimum required version of less than 10.7 (no matter which sdk you use) will cause a linker error. |
Ah, ok, didn't know that. The README_OS_X needs updating then... |
Yes, I think officially supporting a couple of prior versions at the most is reasonable. In the past interested parties used to maintain forks for older OSs, which I think is fair enough given limited dev resources. |
Does a Mac person want to pres the MERGE PULL REQUEST button? |
I was able to apply the merge and build on 10.9! /*
|
Forgot one thing... It would probably be best if someone on 10.7 or 10.8 tested as well. /*
|
I too. But in order to build successfully with Qt, it seems one has either to use SDK 10.8 or a pre-release Qt 4.8.6. If one builds with SDK 10.9, the option to switch off App Nap from the GetInfo menu becomes unavailable (and setting it via defaults write ... becomes uneffective) - and then sclang goes to sleep after a short while if no gui is in the foreground. |
Disabling app nap should be pretty simple, something like:
|
Hi Seth,
[ 63%] Building CXX object lang/CMakeFiles/libsclang.dir/**/QtCollider/hacks/hacks_mac.mm.o But thanks, we're getting closer, I think... Seth's PATCHFrom dbab41ce699e247e1ff7c6fa8bc01eb9d617db95 Mon Sep 17 00:00:00 2001 QtCollider/QcApplication.cpp | 9 +++++++++ diff --git a/QtCollider/QcApplication.cpp b/QtCollider/QcApplication.cpp +#ifdef Q_WS_MAC @@ -77,6 +81,11 @@ QcApplication::QcApplication( int & argc, char ** argv ) +#ifdef Q_WS_MAC diff --git a/QtCollider/hacks/hacks_mac.hpp b/QtCollider/hacks/hacks_mac.hpp bool isKeyWindow ( QWidget *w ); } // namespace Mac +void disableAppNap ( )
} // namespace Mac
|
Hi Bagong, another try... I actually tested this one. ;-) Also, this now seems to compile against the 10.8 SDK (avoided using new constants). This patch should also disable appnap if you compile against 10.8, but run on 10.9 (it does runtime detection of the method call, not compile time). So it should be a fairly universal "blunt hammer" solution to app nap. Arguably, as I understand the event architecture, QtCollider maybe should /not/ call disableAppNap(), since its not latency critical (?), and maybe people do want QtCollider napping when its in the background? Hard to say. In any case, the patch below currently attempts (and seems to succeed in...) to disable appnap on all 3 processes (QtCollider, sclang, scsynth). Let me know how it works for you. I'm not sure how to manage a git change that relies on an existing PR, but I can open a new PR if you want for this. I'm pretty git-ignorant still, so lemme know what works best for you guys.
|
Hi Seth, how nice that you keep going!! I've applied your patch. It compiled fine (both against SDK 10.8 and 10.9 and it appears to be doing the job as intended. No more 'yes' in 'Activity Monitor/Energy' and the server reboots instantly as in the past. I think this is great, and I think a separate pull request would be the best, honour your initiative and set a separate topic. A few small considerations:
Last but not least: unfortunately the SC community is currently not very compact as to github-use. I think you would get the most competent feedback (and an interesting discussion), if your patch was also posted on sc-dev. Have you joined it already? I am sure your participation would highly appreciated! Thanks for all of this |
I can confirm this builds and runs on 10.8 using the 10.8 SDK. Shall I push the button? |
Doesn't seem to build on 10.8 with the 10.7 SDK, but the error seems unrelated: /tmp/testVecLib/lang/LangSource/GC.cpp:801:11: 'MacTypes.h' file not found |
There used to be a version check in an earlier version of the patch which apparently is still required, but with PRE_10_8 rather than 10_7:
|
Probably just not awake yet, but the option seems not to be there. cmake .. -GXcode -DMACOS_SDK_PRE_10_7=ON … CMake Warning:
|
Well I am not sure it is the solution, I just observed that there used to be a version check for MacTypes.h-path in Holgers original patch. It was removed later: https://github.com/mortuosplango/supercollider/commit/a73b0a079a0413c5b7b1062e3311e086b6300fc3 Maybe the old path is still required when building against 10.7 SDK? |
btw, i would not spend too much effort on 10.7 sdk compatibility:
apple continuously changes its APIs. making it almost impossible to have the same code compiling on 3 different osx sdks. it is a great way to waste time, though |
easier:
|
So should I add this back or will 10.7 sdk now be dropped, too? |
nobody is actively dropping anything ... people simply don't care ... :/ however it does make sense to actually read the code and see what is going on: this file is included, but apparently none of its content is used. so why in include it in the first place? |
Just knowing that you care is enough to make it a Merry Christmas for everyone, Tim! :-) I can confirm that with that include removed it builds against the 10.7 SDK. So I'd suggest decrufting and then merging. |
Yesss! Merry Christmas to everybody...
Rough process but nice result ;)! |
That was fun. Happy Christmas! |
Mac OS 10.9 SDK compatibility Seems to have been sorted, so merging
Don't know if that's too much for one patch or if the naming should be changed.