Building on modern macos/xcode versions

[sharpenedblade]

I am trying to fix builds on Xcode 15. I got parts of the code compiling, but the stuff in Mac-Specific is broken. What does Oolite-docktile and Oolite-importer do? Are they necessary for the game?

[Cholmondely]

I am trying to fix builds on Xcode 15. I got parts of the code compiling, but the stuff in Mac-Specific is broken. What does Oolite-docktile and Oolite-importer do? Are they necessary for the game?

Welcome to the friendliest bulletin board this side of Riedquat!

I seem to be the main AppleMac enthusiast but, alas, have the programming skills of Phantorgorth's pet penguin!

Our programmers seem more to be experts in Windows and Linux.

Whilst our first two lead developers were AppleMac experts, Aegidian retired in 2006 - but sometimes surfaces here, whilst Jens seems to have been devoured by the Witchspace Lobster. Our other AppleMac developers (Kaks etc) seem to have met similar fates!

There are some recent notes about this sort of xcode building thing dotted around on this BB. The last AppleMac nightly was produced in February last year by Getafix (not an AppleMacist - he was just implementing the routine which had always worked in the past for doing such)

[hiran]

I am trying to fix builds on Xcode 15. I got parts of the code compiling, but the stuff in Mac-Specific is broken. What does Oolite-docktile and Oolite-importer do? Are they necessary for the game?

I had a quick look at the code, and not knowing Mac related stuff or the history of Oolite code I can only say that there is no documentation explaining it's purpose or how to make use of it.

Oolite-importer seems to grab metadata from savegames and expansions. I am wondering why such code should be Mac-specific.

For Oolite-docktile I found this:
Dock tile plug-in: manages dock menu when Oolite is docked but not running
under Mac OS X 10.6 and later.
https://github.com/OoliteProject/oolite ... lugIn.h#L5

[sharpenedblade]

I dont think we need Oolite-docktile, it doesnt seem to do much and its hard to compile

Update: I deleted Oolite-docktile, but now clang-frontend crashes when compiling libjs. Im going to try to compile it with gcc.

Update2: The error is on line 229 in jslock.h:

Code: Select all

#if defined JS_THREADSAFE && defined __cplusplus
namespace js {

class AutoLock {
  private:
    JSLock *lock; // <--- HERE

  public:
    AutoLock(JSLock *lock) : lock(lock) { JS_ACQUIRE_LOCK(lock); }
    ~AutoLock() { JS_RELEASE_LOCK(lock); }
};

}
#endif

[sharpenedblade]

Initial code here https://github.com/sharpenedblade/oolit ... mac-builds, I messed with submodules so you might need to clone the whole repo.

[sharpenedblade]

The last AppleMac nightly was produced in February last year by Getafix

How did he do this? Did it build with xcode 7.3 in a VM. I think I hit a bug in clang when compiling libjs (jsprf.cpp), so it might not be possible to build without upgrading spidermonkey. I dont understand the actual code, so I cant tell if theres a deprecated stuff or anything.

[phkb]

How did he do this? Did it build with xcode 7.3 in a VM.

I'm not sure what version of XCode he used, but I believe it's an older version in an old VM we have purely for creating Mac releases.

[hiran]

The last AppleMac nightly was produced in February last year by Getafix

How did he do this? Did it build with xcode 7.3 in a VM. I think I hit a bug in clang when compiling libjs (jsprf.cpp), so it might not be possible to build without upgrading spidermonkey. I dont understand the actual code, so I cant tell if theres a deprecated stuff or anything.

There was something about the compiler and assembly code. Something about a 'virtual' flag.
It changed it's behaviour so a warning turned into an error.
Oh look what I found: https://bb.oolite.space/viewtopic.php?p=282107#p282107

[sharpenedblade]

Im going to try to build on a macos 10.14 VM with xcode 7.3

[hiran]

Probably I mixed up two different threads both of which focus on building Oolite. This one seems more appropriare for it so here's my post again:

I configured Doxygen to also generate documentation for the Mac-specific code. The result is visible here:
https://ooliteproject.github.io/oolite/files.html

The interesting part might be the call graphs. If they are not completely off, it looks like some of the functions are never called. Could that mean the code is not required at all?

Thinking about that: Why should a posix build not work on MacOS? Yes, it may sound weird to develop in Objective-C and then run GNUStep on a Mac, but could that remove one big dependency?

[sharpenedblade]

> Why should a posix build not work on MacOS? Yes, it may sound weird to develop in Objective-C and then run GNUStep on a Mac, but could that remove one big dependency?

GNUStep or apple objective C doesn't change much, libjs (spidermonkey) is the one that refuses to build. The code doesnt build and is really hard to modify since its from the 2000s and theres no docs anymore. Do we really need spidermonkey 1.8.5, javascript hasnt broken backwards compat in a long time and porting to a new spidermonkey version isnt too painful.

Im really close to getting it to build in an old VM, but I havent tested if it actually runs yet.

[phkb]

Do we really need spidermonkey 1.8.5, javascript hasnt broken backwards compat in a long time and porting to a new spidermonkey version isnt too painful.

We would have to test a *lot* of OXP's to ensure any newer version would work. Plus, we'd then need to repeat the process on the Windows and Linux builds.

Certainly give it a try. If you can get a newer version to work, and if you test a bunch of OXPs and they continue to function, that's great. But integrating it back into trunk is not going to be easy.

I'd also check out this thread: https://bb.oolite.space/viewtopic.php?f=8&t=21476
another_commander has some insights into what's involved in updating libraries, and the pitfalls thereof. Obviously, it's relating to the Windows build, but the concepts will apply generally.

[Cholmondely]

> Why should a posix build not work on MacOS? Yes, it may sound weird to develop in Objective-C and then run GNUStep on a Mac, but could that remove one big dependency?

GNUStep or apple objective C doesn't change much, libjs (spidermonkey) is the one that refuses to build. The code doesnt build and is really hard to modify since its from the 2000s and theres no docs anymore. Do we really need spidermonkey 1.8.5, javascript hasnt broken backwards compat in a long time and porting to a new spidermonkey version isnt too painful.

Im really close to getting it to build in an old VM, but I havent tested if it actually runs yet.

Wishing you every possible success.

...but did you see this?

What I would like to understand (really just a pointer please) is why we need to stick to an old SpiderMonkey version on any platform, or why a change would break 300-400 OXPs.

Good qustion. Two main reasons:

Portability: Spidermonkey for Oolite is built with certain flags specifically for Oolite. On three different platforms. Going to a more recent Spidermonkey does not guarantee that all platforms will be able to follow through. Windows in particular is the trickiest to build from source and - I could be wrong on this but I don't think so - it may even be impossible to build with the current development environment in use. And this is the small part.

API compatibility and engine interfacing: There is no guarantee that the scripting API remains the same as what we currently have in the game in later Spidermonkey versions. All OXPs containing scripts for Oolite have been built using standard ECMA 5 Javascript of course, but the real problem lies within how the scripting engine has been implemented in the game. Going to a more recent JS version may require a considerable rewrite of the interface between game angine and scripting engine. Even if we assume that we can build successfully a new Spidermonkey for all platforms, the guts of the scripting engine will certainly have to be remade to support the more modern way that the new scripting engine gets interfaced to and interacts with the host application. It is at this point where I expect all OXPs with scripts to start breaking down. Not because they will contain invalid or deprecated JS, but bevause there will be glorious bugs and crashes from the scripting part of Oolite's engine as the upgrade is in progress, at least until the interface with JS gets rebuilt completely and confirmed fully working. Note that this might require a few release cycles.

We can also not exclude that there might have been changes also in the JS API itself since the days of the one we have now. In this case, OXPs may indeed start failing because of the way they are written. Those may need to have their scripts adjusted to work with the latest JS version, but I have no further information on this one.

Of course, we also need to consider the time that will be required to study how exactly new Spidermonkeys are attached to an application. Jens' work on the current scripting engine was not done in a couple of days; it took a lot of work, research and a lot of studying and all this will have to be repeated if we were to proceed with an upgrade. So if anyone feels ready to rewrite the Oolite scripting engine from scratch (when we already have something that works fine, albeit old), now it would be a good time to step up. And maybe provide a way to build the latest Spidermonkey for Windows too, because I am not going to do it - did it once and was more than enough (and switching development environment is not a solution I am prepared to take on, because that would mean that the entire support libraries set distributed with the game will have to be rebuilt for the new dev environment too).

[sharpenedblade]

I dont think building spidermonkey on windows is that hard anymore, the mozilla docs say its just a few commands (that can be run from make) https://firefox-source-docs.mozilla.org/js/build.html. Actually rewriting the code will probably take a lot of effort, but im going to try updating spidermonkey to the next point release (from ~2001).

[Cholmondely]

I dont think building spidermonkey on windows is that hard anymore, the mozilla docs say its just a few commands (that can be run from make) https://firefox-source-docs.mozilla.org/js/build.html. Actually rewriting the code will probably take a lot of effort, but im going to try updating spidermonkey to the next point release (from ~2001).

Thy eminence!

How goes it?