Windows MSYS2 MinGW64 environment development

[another_commander]

As far as I recall, there are currently no further bugs with the modern_build that have been found so far. Please let me know if I've missed anything.

Not sure if it is a bug, a feature or something else, but the .GNUstepDefaults file is no longer called .GNUstepDefaults. It is now called $(PRODUCT_BUNDLE_IDENTIFIER).plist, which I believe is actually meant to be the application bundle name. This feels like a bug. Additionally, this file is now in XML format, while in Windows it is expected to be NextStep. The Linux version also has this file in XML format, but that happened only after the GNUstep project decided at some point years ago to switch the defaults file to XML. Before that, all ports had their defaults file in NextStep format and Windows just kept it even after the upstream change occurred because NextStep is more human friendly. This is a strong departure from what we had and, to top it off, any and all references in the wiki or in the forum giving advice about .GNUstepDefaults are now invalid (or at the best case confusing) since this file is no longer present.

The only thing you had mentioned is the file size of libicudt77.dll. That comes from https://github.com/msys2/MSYS2-packages ... u/PKGBUILD. If it's a big problem, that package can be built with specific locales to reduce file size. The locale specification is here: https://github.com/unicode-org/icu/blob ... le-slicing

I wouldn't worry too much about it. I don't like the bloat, but it is not a functional problem that deserves spending time on. SSD drive sizes are not an issue in our day. It's just that the original binary distribution is much more compact and elegant.

If all is well, my next idea is to make a GH Action release of the packages (EDIT: see https://github.com/mcarans/oolite_mingw ... /tag/0.0.1) and in a separate repo, to see if it's possible to make a GH Action that downloads those release packages (latest version), installs them in a fresh MSYS MinGW64, then builds the nsis Oolite package, enabling the automation of a versioned Oolite release with pre-built versioned packages.

Go for it. BTW, re the dev environment, there should be an automatic execution of the <mingw64Folder>/share/GNUstep/Makefiles/GNUstep.sh script when the environment starts up or you can't build Oolite (i.e. source <mingw64Folder>/share/GNUstep/Makefiles/GNUstep.sh in etc/profile or similar). When the build script runs and downloads everything etc. it works, but subsequent launches of mingw64.exe do not get that GNUstep.sh shell script to launch and I had to do it manually, which is a pain.

[mcarans]

Not sure if it is a bug, a feature or something else, but the .GNUstepDefaults file is no longer called .GNUstepDefaults. It is now called $(PRODUCT_BUNDLE_IDENTIFIER).plist, which I believe is actually meant to be the application bundle name. This feels like a bug. Additionally, this file is now in XML format, while in Windows it is expected to be NextStep. The Linux version also has this file in XML format, but that happened only after the GNUstep project decided at some point years ago to switch the defaults file to XML. Before that, all ports had their defaults file in NextStep format and Windows just kept it even after the upstream change occurred because NextStep is more human friendly. This is a strong departure from what we had and, to top it off, any and all references in the wiki or in the forum giving advice about .GNUstepDefaults are now invalid (or at the best case confusing) since this file is no longer present.

Does Lone Wolf's comment shed any light on it?

$(PRODUCT_BUNDLE_IDENTIFIER).plist is also present (and used) on source builds for linux trunk & stable on archlinux.

The generic installer for linux 64-bit does use .GNUstepDefaults .
Maybe the method used to create pre-built binaries makes changes to the sourcecode/config settings before building ?

[mcarans]

Go for it.

Here is a release of Oolite's installer built using the latest packages: https://github.com/mcarans/oolite_windo ... /tag/0.0.1

As for the plist format, I believe it can be set to one of these:

Code: Select all

enum {
  NSPropertyListOpenStepFormat = 1,
  NSPropertyListXMLFormat_v1_0 = 100,
  NSPropertyListBinaryFormat_v1_0 = 200,

  NSPropertyListGNUstepFormat = 1000,
  NSPropertyListGNUstepBinaryFormat
};

https://github.com/gnustep/libs-base/bl ... List.h#L58

[another_commander]

Here is a release of Oolite's installer built using the latest packages: https://github.com/mcarans/oolite_windo ... /tag/0.0.1

Downloading now to test drive it.

As for the plist format, I believe it can be set to one of these:

Code: Select all

enum {
  NSPropertyListOpenStepFormat = 1,
  NSPropertyListXMLFormat_v1_0 = 100,
  NSPropertyListBinaryFormat_v1_0 = 200,

  NSPropertyListGNUstepFormat = 1000,
  NSPropertyListGNUstepBinaryFormat
};

https://github.com/gnustep/libs-base/bl ... List.h#L58

Yes, we want the first one in the enum and you need to modify NSUserDefaults.m in the gnustep-base source, writeDictionary function.

[mcarans]

Yes, we want the first one in the enum and you need to modify NSUserDefaults.m in the gnustep-base source, writeDictionary function.

I have made that change by way of a patch used in the PKGBUILD for gnustep base.

I've added the following to the install.sh to handle GNUstep.sh and history:

Code: Select all

cp /mingw64/share/GNUstep/Makefiles/GNUstep.sh /etc/profile.d/

if ! grep -q "# Custom history settings" ~/.bashrc; then
  cat >> ~/.bashrc <<'EOF'

# Custom history settings
WIN_HOME=$(cygpath "$USERPROFILE")
export HISTFILE=$WIN_HOME/.bash_history
export HISTSIZE=5000
export HISTFILESIZE=10000
shopt -s histappend
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
EOF
fi

I'm puzzled about where $(PRODUCT_BUNDLE_IDENTIFIER).plist comes from. I gather it's what Cocoa does rather than GNUstep and is usually set though XCode.

[mcarans]

Changing CFBundleIdentifier in src/Cocoa/Info-Oolite.plist from "$(PRODUCT_BUNDLE_IDENTIFIER)" to say "Oolite" allows us to set a more sensible filename at least: GNUstep/defaults/Oolite.plist

[mcarans]

Not sure if it is a bug, a feature or something else, but the .GNUstepDefaults file is no longer called .GNUstepDefaults. It is now called $(PRODUCT_BUNDLE_IDENTIFIER).plist, which I believe is actually meant to be the application bundle name. This feels like a bug.

I have debugged this issue and have found that modern GNUstep base introduces Persistent Domains and uses {CFBundleIdentifier}.plist as the name which can be set in src/Cocoa/Info-Oolite.plist as previously mentioned. It may be possible to hack GNUstep base to use a new name by making a copy of initWithName in NSUserDefaults.m, changing the hacked copy to use .GNUstepdefaults instead of {CFBundleIdentifier}.plist and using it here:

Code: Select all

	  pd = [[GSPersistentDomain alloc] initWithName: bundleIdentifier
						  owner: self];

This would (hopefully) set the output file to .GNUstepDefaults for both Windows and Linux.

However, ideally I think it's better not to make hacks like this and to update the documentation to refer to the correct file instead: we could decide a sensible value for {CFBundleIdentifier} in src/Cocoa/Info-Oolite.plist such as "Oolite" or "Oolite-Defaults" which would create a file "Oolite.plist" or "Oolite-Defaults.plist" and then refer to that file in the wiki + make a post on the forum explaining the name change. The file format would stay as OpenStep (patch already included) so it's only the filename that will change to an arguably clearer and better name (with the directory remaining the same). If you wanted to make the name really close, you could set {CFBundleIdentifier} to "GNUstepDefaults" or maybe even ".GNUstepDefaults" in which case the file would be "GNUstepDefaults.plist" or ".GNUstepDefaults.plist". What do you think?

[another_commander]

I agree. OoliteDefaults.plist doesn't sound bad at all to me.

[mcarans]

I agree. OoliteDefaults.plist doesn't sound bad at all to me.

I have made that change in the modern_build branch
https://github.com/OoliteProject/oolite ... c8e80f1a16

I've kicked off release 0.0.2 of packages that includes OpenStep format patch in GNUstep Base. https://github.com/mcarans/oolite_mingw ... 8626316216

Edit : something went wrong with that build. I'll check tomorrow

[mcarans]

I agree. OoliteDefaults.plist doesn't sound bad at all to me.

Updated packages are here: https://github.com/mcarans/oolite_mingw ... /tag/0.0.2

New installer is here: https://github.com/mcarans/oolite_windo ... /tag/0.0.2

Installer worked fine for me. Let me know how you get on.

[another_commander]

Latest installer seems to work fine here.

[mcarans]

Latest installer seems to work fine here.

Ok, that's good. Are there any others who can test it? When we are good to start the merge process, I will need to transfer repositories to OoliteProject and create a PR for the modern_build branch.

[another_commander]

Whenever you feel ready let me know, I'll add you as a developer in Oolite and you will have write access to the game's repo.

For a few months we need to be running the modern and the "classic" builds in parallel just to be sure.

[mcarans]

Whenever you feel ready let me know, I'll add you as a developer in Oolite and you will have write access to the game's repo.

For a few months we need to be running the modern and the "classic" builds in parallel just to be sure.

I am ready now - I have nothing to add to the process. I already added error handling to the GitHub workflows so that if something goes wrong, they fail properly and stop.

I think the next thing will be to try to do the same in Linux for Flatpak, a process which I can see was started in a PR. If that can be made to consistently build a Flatpak in GH Actions in much the same way as the Windows installer and using similar dependencies to the Windows build (eg. libs-base with GNUStep OpenStep fix), then we will be in a much better place.

Once we're happy with the modern build on Windows and it becomes the default, a simple future experiment to try is using MSYS2 MinGW64 system NSPR instead of building it (the steps should be as simple as just removing the built NSPR package using Pacman, installing the system NSPR package and rebuilding the JS library and Oolite). I would also like to submit pcaudiolib and espeak-ng to be packages in MSYS2 so that there are less dependencies that need to be built for Oolite (and making those libraries available to all MSYS2 users).

EDIT: I couldn't resist trying the system NSPR since it's so easy to switch with everything as pacman packages. The JS library built fine with it as did Oolite. The game seems to work fine too. What are your thoughts on using the standard MSYS2 MinGW64 package instead of building it from my copy of your repo?

[another_commander]

EDIT: I couldn't resist trying the system NSPR since it's so easy to switch with everything as pacman packages. The JS library built fine with it as did Oolite. The game seems to work fine too. What are your thoughts on using the standard MSYS2 MinGW64 package instead of building it from my copy of your repo?

Whatever feels easier for you is fine as long as it all works.

Regarding installers, we need one more installer for generating Test Release builds. The one we have generates Deployment configurations only. Alternatively we need a converter mini-installer to be able to go from Deployment to TR in one click. But in any case being able to generate TR installers for any reason the developers may consider appropriate is desirable.

As far as your inclusion to the dev team, I am currently out on business trip and can't do it just yet. Will be done upon returning to base.