The International Simutrans Forum

I have tried github actions to build an MAC OS release. Lacking MAC OS, I could not test the result. Could someone with a MAC please download and test it, please?

It probably requires SDL2, frettype, and miniunpnpc. Again, no way to test.

So what needs testing? Building on MacOS? Or running a pre-built on MacOS?

It is a nightly build on Mac OS using github actions. I have no idea if it actually runs on a vanilla Mac OS. Maybe it needs more static linking ...

Doesn't work on my ancient Mavericks box - requires QTKit not AVF. i.e. Don't set AV_FOUNDATION=1 in config.default. I have nothing that can run a newer OS to try.

dyld: Symbol not found: _OBJC_CLASS_$_AVMIDIPlayer
  Referenced from: /Users/..././simutrans
  Expected in: /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation
in /Users/..././simutrans
Trace/BPT trap: 5


It looks like you've used 'homebrew' for libraries rather than native mac ones as previous releases have used (I couldn't find native libraries for freetype or miniupnpc which is why the last release for mac had those disabled. [and sidenote - I see release files for a 121.0 version on sourceforge but the forum still shows 120.4 as latest and even has an announce thread for 120.4.1 in the forum too...)

This rather increases Simutrans dependencies from a simple SDL2 framework install to an entire homebrew suite and special brew packages for sdl2, freetype, upnp...  It took >45 minutes to get all that installed - I doubt a typical mac user would bother past the first crash.

Also, the binary should be put in the bundle for friendliness of not having an extra console window open (and then get stuck open until manually closed). I'd provided both the app bundle for normal use (shows only the simutrans window), and the regular executable (also shows the console) in past releases. Actually it's the same executable, just seems macos suppresses the console when run from an app bundle. buildOSXbundle.sh is the script in trunk to do as it says, although outdated so I just did it manually.

Well, turns out the distribute.sh is not downloading SDL2 and packing for MacOS, since it uses the obsolete darwin os type ... (And the build environment at github only supports AVfoundatiohs anyway). So now I bundle with SDL2. Linking with freetype should create no issue, as freetype is with MacOS. (However, the header I need to download with brew, I hope this creates no further issues.)

The build would be at https://github.com/prissi/simutrans/releases/download/Nightly/simumac-nightly.zip

EDIT: Bundling with DMG seems more complex on macos commandline. So no recent build on the above link!

Could someone try again this version again https://github.com/prissi/simutrans/releases/download/Nightly/simumac-nightly.zip. It is just assuming one had installed SDL2 via DMG download.

It's still looking for the homebrew freetype:

dyld: Library not loaded: /usr/local/opt/freetype/lib/libfreetype.6.dylib
  Referenced from: /Users/.../simutrans.app/Contents/MacOS/simutrans
  Reason: image not found
Trace/BPT trap: 5


I've posted some commits to a fork of the simutrans git mirror (https://github.com/EricFromCanada/simutrans (https://github.com/EricFromCanada/simutrans)) which should help get the Mac nightly build working again by e.g. including a pakset and integrating the shared libraries into the app bundle. With changes applied, rough instructions for building the nightly on macOS are:

- install build dependencies from Homebrew (https://brew.sh (https://brew.sh)):
  brew install autoconf automake freetype libpng pkg-config sdl2
- compile:
  autoreconf -ivf
  ./configure CC=clang
  make BACKEND=sdl2 MULTI_THREAD=1 OPTIMISE=1 OSTYPE=mac USE_FREETYPE=1 USE_UPNP=0 USE_ZSTD=0 AV_FOUNDATION=1
  make OSX/getversion
- build app and compress for distribution:
  ./distribute.sh

This is very helpful. Just a question: Will this run without brew installed at the end user. Because if brew is required, this would be a no go.

Somehow your workflow does not show action builds. Did you test it with the github actions?

The install_name_tool lines in distribute.sh modify the simutrans binary to look for shared libraries inside the app's Frameworks folder, so it should run without needing any dependencies installed using Homebrew. I've only tested building in my own Terminal though; I haven't tested anything with GitHub Actions so far.

I submitted your changes in r9205. Lets see if this generates an universal build

I have tried the new nightly download.
The app just exits
If I run the executable in the app from the command line it asks me for a pak
I chose the British pak - it then downloaded and then runs.
A fix to this might be to puit a pak in the bundle and either load from the bundle and a downloading place or copy from the bundle to a downloading place (probably

I also tried a build from source (after passing around the correct flags  - I use Macports so need to add to the include and lib paths) I get error
FATAL ERROR: loadsave_t::rdwr_xml_number() - expected "<i8>", got ""
when trying to read simutrans.xml
Where is this file I can't find it but it is opened somehow

QuoteThe solution: go to %user/documents/simutrans and delete the files default.sve and settings.xml. Deleting both files will make the game generate new default ones and it will work just fine.

the files are where the saves stored
I don't know where in mac maybe in the home directory of the user

I think for Linux and MAC a call to gat_pak.sh to install some pakset might be the best solution. So Simutrans gets its own update dialog. (May still fail if neither unzip wget or curl is on the machine.)

I reran the app from the overnight build. It works if you unzip the whole release but if you move the app somewhere else it then fails.

Looking at bits of code my guess is that it is using the directory the app is in to load data. Unfortunately this is not the Mac way. This might be OK for manual use but not for Steam.

Everything that is needed to start must be inside the bundle.

I also note that osx.mk has a bundle target that is still active, but the code there still refers to PPC builds so is probably 10 years old.

Also for debugging the app bundle should be part of the build nopt the deployment
When was the last time that there was a working OSX build?  Is the Windows version build from the autotools files or is it a separately maintained set of MS Visual Code files?

All releases are built from autotools.

The last working version I had, was a PPC Mac version, running from commandline. But the bundle is more recent, from 2017 or so, when there were still PPC/Intel dual releases.

The current nightly is built on github, since this is the only way to access a Mac for any of the active developers.

QuoteEverything that is needed to start must be inside the bundle.

What you mean by bundle? I am not really familiar with MacOS terminology. Do you mean that game content should be in some other Lbrary folder, in priciple, like for Debian too.

No a Bundle is a directory with a particular extension e.g. .app or .bundle or several others. Which in MacOs the user sees as one thing.

For example a program is a .app directory, which is installed by dragging one thing to /Applications.  Consider it is like a zip file that the user does not ever unzip, they just copy or run it , the code in the program knows how to navigate it. In detail the code just manipulates files so the same C code can still be used.

Thus everything has to be in that one directory and be read only.

When the app starts if it needs to write to this data it has to acquire a known place to write to - you have chosen ~/Library/Simutrans (which is OK but a bit early 2000 development choice and might need to be changed to fit Apple sandboxing requirements if you want to distribute via Steam). If the data supplied by the app can be edited then it needs to be copied from the app bundle to this directory. For more see https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19

If you have no Mac developers I would ask how many Mac users have you got and is it worth the effort to make the system run?

Another issue I saw is that I got a runtime comment that Simutrans is better as a 32 bit executable - that is a big problem as macOs now (from Catalina released last year) only supports 64 bit executables.

Given these points is it worth attempting a mac port. I think I could do it but then how will the simutrans developers be able to support it?

I have set up a Mac VM to try and get the Mac version running for Steam, and followed CannonBall's instructions:

Quote from: CannonBall7 on October 14, 2020, 10:17:13 PM- install build dependencies from Homebrew (https://brew.sh):
  brew install autoconf automake freetype libpng pkg-config sdl2
- compile:
  autoreconf -ivf
  ./configure CC=clang
  make BACKEND=sdl2 MULTI_THREAD=1 OPTIMISE=1 OSTYPE=mac USE_FREETYPE=1 USE_UPNP=0 USE_ZSTD=0 AV_FOUNDATION=1
  make OSX/getversion
- build app and compress for distribution:
  ./distribute.sh

Now I can open Simutrans (it will crash unless I disable MIDI, but that's a problem for another day), but only if I have the libraries installed from brew. If I uninstall the libraries, I get:

Quotedyld: Library not loaded: @rpath/../Frameworks/libfreetype.6.dylib

My experience with linux's rpath (and what I've read online so far) tells me that this rpath is ok, but obviously something is wrong. I have tried workarounding this issue adding an @executable_path. It then loads freetype.lib, but freetype.lib asks for /usr/local/opt/libpng/libpng16.16.dylib instead of looking in just the same directory it is! I cant' do the same for libfreetype, so I'm stuck again.

I will try to continue tomorrow.

Btw, nitghly builds are not working (again).

The nightly build for 11th October seems OK. I don't have the brew libraries installed (I use macports which puts them in a different place) so the executable can't be finding them



Actually the nightly build seems not to have used the command line you give. otool -L simutrans says it only has SDL2 as a third party library and was build with QTKit not AVFoundation

otool on a Mojave machine says

otool -L simutrans.app/Contents/MacOS/simutrans                                             
simutrans.app/Contents/MacOS/simutrans:
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
   /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.17.0)
   /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)
   @rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 8.0.0)
   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
   /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0)
   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)


And it works on my machine as I have SDL2.framework from 2016 in my ~/Library/Frameworks and copying that to Contents/Frameworks - works.

The nightly build must have been from before the distribute.sh changes as it did not have the Frameworks directory

OK I now read the whole thread and see we are back to reply $5 and the reason to change is the github build as github cannot load the SDL2.framework.

Can we do the old way of using third party libraries and put a copy of the SDL2 framework in our version control?

OK I am now really confused and probably confusing others.

I must have used the Sourceforge release of October 11 which runs as I have SDL2.framework installed.

My comments on bundles still apply - which are needed for Steam and proper macOS support.

Is there a nightly build available - and if so where.
Similarly all these github actions where are these run and where can we see th logs and the produced artifacts

Nightlies are released on https://nightly.simutrans.com/es/ . There's no current nightly, but you can download an older version from 18th october, which was compiled with freetype support with the changes proposed previously by CannonBall. If you try to run it, you will probably run into the very same problem as me.

EDIT: direct link to last nightly https://nightly.simutrans.com/download.php?os=Mac&r=9303

Oh it is worse - I am on Mojave - macOS 10.14.6 The app says I need macOS 10.15 (Catalina) or later.

I can confirm that the freetype issue is there. otool -L shows
   /usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.2.0)

For now do we really need freetype - if not then build without it.
Then I think from reading the github action  there are two bugs with the github build of January (ie no need to install_name_tool)
1) SDL2.framework needs to be copied into the app bundle
2) Fix the macOS version needed - this should be possible by the correct compile flags but I need to study them as I  only build for myself now and I don't know if github builds support this.

There are two MacOS environment on Github.
macOS Big Sur 11.0
macOS Catalina 10.15
I can happily switch to MacOS 11.x

Also I need more instruction what works and what not. If I read correctly, I should revert the change to the MacOS runn on the 11th?

The newer builds have a framework folder with dylibs. Please download from here: https://github.com/aburch/simutrans/releases/download/Nightly/simumac-nightly.zip

I set the build OS now to 11.0. Maybe this shoudl solve the compatibility issue. Please download form above in about six hours from now (about evening in Europe)

Quote from: Roboron on October 24, 2020, 01:59:37 AMI cant' do the same for libfreetype

Actually, I can, I just needed to use sudo (lol). Now I have a self-contained Mac OS simutrans.

Quoteotool -L simutrans.app/Contents/MacOS/simutrans
simutrans.app/Contents/MacOS/simutrans:
   @executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.4.0)
   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
   /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
   @executable_path/../Frameworks/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1677.104.0)
   /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
   @executable_path/../Frameworks/libSDL2-2.0.0.dylib (compatibility version 13.0.0, current version 13.0.0)
   /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
   /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
   /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
   /System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
   /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
   /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
   /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
   /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
   /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0, weak)
   /System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 212.8.0, weak)
   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
   /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)

A link: https://michan.noho.st/nextcloud/s/gKaP2BarHoKwWRT

Unfortunately, this has been compiled on my VM running macOS Big Sur 11.0, so it may not work on previous versions.

Attached there is the patch with necessary changes to ./distribute.sh for this to work, so GitHub Actions can take care of other macOS versions.

Now, time to test it on Steam.

It works! No more modifications needed. Simutrans on Steam is back on Mac :_D

Unfortunately fails for me with error


Termination Reason:    DYLD, [0x4] Symbol missing

Dyld Error Message:
  Symbol not found: _objc_opt_respondsToSelector
  Referenced from: /Users/USER/Library/Application Support/Steam/*/simutrans.app/Contents/MacOS/../Frameworks/libSDL2-2.0.0.dylib (which was built for Mac OS X 10.15)
  Expected in: /usr/lib/libobjc.A.dylib

I am on macOS 10.14.6

I think this is because brew builds for the current OS and on github this is 10.15

However well done Roboron.

I will still try the old framework build to work as it is built with minimum version of 10.6 (a bit excessive but we will see)

Thanks, I try this for the normal build too.

By the way, the current SImutrans gets also a paksetinstaller for all other OS (including MacOS), if the target OS allows writing to the target dir,

Quote from: mark1878 on October 24, 2020, 01:54:53 PMI am on macOS 10.14.6

I think this is because brew builds for the current OS and on github this is 10.15

This is a difficult situation to solve. We can't target every version of macOS, specially if the build system (and me) only have access to 10.15/11.0 :/
I would like to provide more support for older versions on Steam, but in this situation the only thing I can do is to target the lastest macOS versions and let the users know that no official support will be available for any other version that is not the last one.

However, if you (or any other mac user) want to provide a build for older versions, follow CannonBall's instructions (my fix for the linked libraries is now incorporated on the svn), and provide me with the simutrans.app, so I can publish it as an additional branch.

This thread became quite messz. Anzwaz, please MacOS user test also the latest MacOS nightly, if it works (and maybe even install pakset). It shoudl work with any OS newer than 11.0

Quote from: prissi on October 25, 2020, 11:38:11 AMplease MacOS user test also the latest MacOS nightly,

There is no new nightly at https://nightly.simutrans.com/ . Is something wrong with the build system? (logs?).

Thank you for the work to support macOS!
I tested the app binary that Roboron provided at yesterday 11:33:43, and got the following error.


dyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
  Referenced from: /Users/THLeaderH/Downloads/simutrans-1/simutrans.app/Contents/MacOS/simutrans
  Reason: image not found


The version of my mac is 10.15.7.


EDIT: Woops, I used the older version. I tested one that Roboron provided at yesterday 12:40:43 PM and it works!
However, the app files works when I launched from the command line, but it fails when I launched with double click. I'm seeing why it happens.

Quote from: THLeaderH on October 25, 2020, 11:55:11 AMdyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2

This is a contradiction! See the previous logs by me and mark, "@rpath..." should be replaced by "@executable_path/../Frameworks/libSDL2-2.0.0.dylib".

Are you sure you did not accidentally open a previous version? (or maybe I zipped a wrong version).

If so, what's the output of "otool -L simutrans.app/Contents/MacOS/simutrans "?

The binary was successfully launched when I executed simutrans.app/Contents/MacOS/simutrans, but immediately exited without any crash logs when I double clicked simutrans.app.

The result of "otool -L simutrans.app/Contents/MacOS/simutrans " is as follows.

@executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.4.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
@executable_path/../Frameworks/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1677.104.0)
/System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
@executable_path/../Frameworks/libSDL2-2.0.0.dylib (compatibility version 13.0.0, current version 13.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
/System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0, weak)
/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 212.8.0, weak)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)


UPDATE: I tried the double clicking of the app file in the environment that Roboron provided and got immediate crash. However, once I copied the app file to the existing environment that I use for my daily play, and the app was successfully launched. I'm seeing what is the difference, but I've not found the cause of this phenomenon.
I also got the immediate crash with the command "open -a simutrans.app"

Quote from: THLeaderH on October 25, 2020, 12:14:20 PMThe binary was successfully launched when I executed simutrans.app/Contents/MacOS/simutrans, but immediately exited without any crash logs when I double clicked simutrans.app.

Weird. I don't have this issue. What happens when you execute "open simutrans.app"?

In Roboron's environment, I got immediate crash without any logs with "open simutrans.app". There are no error logs in console.app.

Quote from: THLeaderH on October 25, 2020, 12:44:27 PMIn Roboron's environment, I got immediate crash without any logs with "open simutrans.app". There are no error logs in console.app.

Ehh... I'm going to assume this is some weirdness by apple (like not executing apps from the downloads folder) and not the actual, usual behaviour. I'm acting like this never happened.

I moved the simutrans testing folder from the Download folder to Document folder, but the same thing happens. Simutrans.app works well in my simutrans environment for daily play, so I believe it's something weirdness by apple. I'll ask to other mac users in the Japanese simutrans community whether they can execute the app or not.

   THLeaderH,
What version of macOS are you running. Where exactly did you download this from?

Apps can run from anywhere under macOS so that is not the issue.

In the download folder can you show what an ls of the simutrans folder is

I now have a build that runs on github. How do I get the resulting zip back to my machine.
I have not used github actions before. I managed after several trys to make it build without errors. (I also had to modify the Windows builds to stop them running - the Ubantu and macOS builds I can stop from the Github GUI)

The code is at https://github.com/bestlem/simutrans/tree/sdl2_mac_framework

The reason for doing this is to try and see if I can get a build that runs on lower macOS versions

I am wondering, if the zipfile was created correctly. Otherwise it should appear under release.

But I saw that brew installs everything for 16.x, even though it runs on 11.0. So indeed, brew cannot be used on github. It is even more difficult, since a freetype library is often present, even though it is not installed by the runner. I found these virtual machines in several states.

re "So indeed, brew cannot be used on github."
That is why I am trying to use the SDL Framework only
brew autotools and autoconfig should are OK as not part of the resulting artifact so it does not matter what version they have.

OK no freetype and a few others but leave that for later (see if we can get them built elsewhere or store in out VCS or build as part of this - all the old 1990s way of getting repeatable builds)

As for the builds - even the main simutrans archive https://github.com/aburch/simutrans  which everyone forks from had a last release on https://github.com/aburch/simutrans SO why are these failing. Even though it has many builds since then.

How did we get a build to sourceforge and Steam - is this documented anywhere?

And of course I did not understand github actions and I got an unexpected build and release - and I deleted that release - as it was off the Jan code - would have been useful to see what happens.

The wonders of languages and environments you can't run locally

autotools sometimes find a freetype on github, if a previous user installed it via brew. The virtual machines are in various states on github.

The nightly is downloaded by another server, which renames it and triggers an upload to simutrans.org. The upload to Sourceforge is manually by myself.

Quote from: prissi on October 26, 2020, 12:26:30 PMSo indeed, brew cannot be used on github.

Does this mean that our only alternative is to compile the libraries we need (freetype, sdl, etc) using github actions?

Quote from: mark1878 on October 26, 2020, 12:47:06 PMHow did we get a build to sourceforge and Steam - is this documented anywhere?

While the process can be automated, for now I manually upload builds to Steam. For the windows build, I just use the one prissi upload to Sourceforge. For the linux one, I compile it myself, it's not the same as the one provided on Sourceforge.
Nightlies builds are automated, but they are just downloaded from https://nightly.simutrans.com/ and then uploaded to Steam.

Quote from: Roboron on October 26, 2020, 01:12:08 PM
Does this mean that our only alternative is to compile the libraries we need (freetype, sdl, etc) using github actions?

For SDL2 no as they have a built framework which you can just copy - which is why I want this simple build
For others we will have to look at each one to see if they have this - otherwise yes we will need to compile ourselves - or perhaps if they offer a built version use that.

But let's get the simple build working first.

Quote from: Roboron on October 26, 2020, 01:12:08 PM
While the process can be automated, for now I manually upload builds to Steam. For the windows build, I just use the one prissi upload to Sourceforge. For the linux one, I compile it myself, it's not the same as the one provided on Sourceforge.
Nightlies builds are automated, but they are just downloaded from https://nightly.simutrans.com/ and then uploaded to Steam.

Sorry Roboron and prissi

It is the stage before I need to know.
I have built the thing in a github action which - and ls shows there is a simumac.zip
How do I get that file out of github and on to my machine.
A working example might be of help here.
e.g. How does the nightly build get to sourceforge

You have to either build it as release or as artefact. https://docs.github.com/en/free-pro-team@latest/actions/guides/storing-workflow-data-as-artifacts#:~:text=Artifacts%20allow%20you%20to%20share,Enterprise%20Server%2C%20and%20GitHub%20One.

I think something like

  - name: 'Upload Artifact'
    uses: actions/upload-artifact@v2
    with:
      name: my-artifact
      path: my_file.txt
      retention-days: 5

may work for you.

Hey everyone,

For what it's worth, the game successfully compiles and runs on 10.14 and probably earlier (had a bit of a weird time with the 'simutrans' folder inside the git repo, but once I sorted things out it worked). I'm not very familiar with how GitHub actions set up their environment, but you should be able to specify an earlier version by setting the env variable "MACOSX_DEPLOYMENT_TARGET" to something like 10.12. It ought to compile and at least try to start on earlier OSes, and I'd expect it works.

It's also generally a safer bet to link libraries statically on macOS, as you've surely noticed using install_name_tool is annoying. The trouble here is that Apple's linker always picks a dynamic library if it finds it (and I do mean always, no matter what settings you use), and homebrew generally loads dynamic libraries as well as static ones. So you'll end up with the dynamic version.
On 0 A.D. we worked around this by building libs manually, but this is quite cumbersome. A very ugly hack is to simply hide the .dylib versions when compiling. You can also keep bundling them with the app.

Cheers anyways.

Thatk you, these are useful hints, especially since I never compiled for MacOS but with github actions. I will try setting the environment variable.

Yes we can compile locally there are no problems with this using various different builds.

The issue is how do we get a git hub build.

This has been done.

How??????????????????????????????
Where is the code which did this.
The obvious git hub is https://github.com/aburch/simutrans but this has not built since January. So what is the build used for Steam

Where have the recent builds come from?

Given this we can progress

What is the official build?

We get comments on how do a build as try xxxx/ The issue is that it has been done. Stop taking guesses. please provide the actual build.

The github built is recent, but the date is fixed to the first time the upload was used. (Otherwise there will be a new release for every submit, since GitHub does not allow to replace releases with the official script.). This https://github.com/aburch/simutrans/releases is the build from the last action, as the svn revision will tell you. At the time of writing, this is the build from 20 h ago: https://github.com/aburch/simutrans/actions

You can also test the files from here.

https://github.com/Andarix/simutrans/releases (https://github.com/Andarix/simutrans/releases)
https://github.com/Andarix/simutrans/blob/master/.github/workflows/macos.yml (https://github.com/Andarix/simutrans/blob/master/.github/workflows/macos.yml)