Topic: New Macintosh release

[Roboron]

In 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.

[THLeaderH]

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.

[mark1878]

   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

[mark1878]

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

[prissi]

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.

[mark1878]

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

[prissi]

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.

[Roboron]

So 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?

How 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.

[mark1878]

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.

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

[prissi]

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

Code: [Select]

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

[wraitii]

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.

[prissi]

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

[mark1878]

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.

[prissi]

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

[Andarix]

You can also test the files from here.

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