The future for the Mac build
Posted: Thu May 15, 2025 5:19 am
For all the Mac users out there, here is a Deployment build of the Mac version, version 1.90, that has a corrected Expansion Manager URL in it: {removed}. If a few people can download and run this on their Macs, and confirm the Expansion Manager is working out of the box, maybe we can host it on the GitHub site. (BTW the version is still 1.90, the "a" is just in the filename of the zip to keep it separate from the original zip.)
I didn't want to have to write this post. I was hoping that with enough perseverance, I could somehow wrangle the Mac code into a functioning state for 1.91. I regret to inform everyone that, even with Bogatyr's brilliance in getting the 1.90 build updated, I still can't get the newest code to work. Apple has quite literally thrown OpenGL under the bus. If it's possible to resurrect the latest trunk on Mac, it will need someone far more knowledgeable than me with Xcode and the Mac in general.
But I'm not quite ready to leave Mac users behind. They may not get to appreciate the graphical updates that have been added to the Windows build, but there are other things that have been added, quite separate to the graphics, that are worth having. The in-game keyboard config for one (and yes, I appreciate that I am quite biased, as I was the one who added that!), but also general bug fixes.
I have a proposal - it's not a very good one, but It's the only plan I can think of that can keep the Mac build going a bit longer. My proposal is to fork the Mac build from the current Oolite project, creating a new Mac-only code base. From there, we can take the build Bogatyr put together, and then individually apply all the patches that have been made to the game in Trunk that aren't related to graphics. By doing this, we bring the Mac build *mostly* up to date, and open up the possibility of actually getting 1.92 over the line (with obviously some work on the Linux build to follow).
The benefit of creating a fork is that we can avoid even more of the "If this is a Mac, do something this way, otherwise do it another way for Windows" code that currently inhabits the codebase. Because it will be just for the Mac, we can do things one way.
The downside of creating a fork is that it effectively doubles the amount of code in the main project. It also means a lot of the documentation will have to be adjusted (specifically code related to building the Mac version).
I'm also fully aware that my ideas aren't always the best, so at this point I'll open the topic up for debate. Maybe there's another option I haven't considered. Please add your comments.
I didn't want to have to write this post. I was hoping that with enough perseverance, I could somehow wrangle the Mac code into a functioning state for 1.91. I regret to inform everyone that, even with Bogatyr's brilliance in getting the 1.90 build updated, I still can't get the newest code to work. Apple has quite literally thrown OpenGL under the bus. If it's possible to resurrect the latest trunk on Mac, it will need someone far more knowledgeable than me with Xcode and the Mac in general.
But I'm not quite ready to leave Mac users behind. They may not get to appreciate the graphical updates that have been added to the Windows build, but there are other things that have been added, quite separate to the graphics, that are worth having. The in-game keyboard config for one (and yes, I appreciate that I am quite biased, as I was the one who added that!), but also general bug fixes.
I have a proposal - it's not a very good one, but It's the only plan I can think of that can keep the Mac build going a bit longer. My proposal is to fork the Mac build from the current Oolite project, creating a new Mac-only code base. From there, we can take the build Bogatyr put together, and then individually apply all the patches that have been made to the game in Trunk that aren't related to graphics. By doing this, we bring the Mac build *mostly* up to date, and open up the possibility of actually getting 1.92 over the line (with obviously some work on the Linux build to follow).
The benefit of creating a fork is that we can avoid even more of the "If this is a Mac, do something this way, otherwise do it another way for Windows" code that currently inhabits the codebase. Because it will be just for the Mac, we can do things one way.
The downside of creating a fork is that it effectively doubles the amount of code in the main project. It also means a lot of the documentation will have to be adjusted (specifically code related to building the Mac version).
I'm also fully aware that my ideas aren't always the best, so at this point I'll open the topic up for debate. Maybe there's another option I haven't considered. Please add your comments.
