FYI GitHub Actions will deprecrate Node12

[Matthew]

GitHub is now attaching a note to both Standard and Extended build Actions warning that Node12 will be deprecated. It points to this blogpost which warns that maintainers(?) need to move to Node16. There is no deadline yet but summer 2023 is mentioned, so it seems not imminent.

I am aware that the GitHub repos aren't officially supported by Standard but I don't know where else to raise it.

I have zero experience with JavaScript so I'd not be the best person to help with this.

[Dwachs]

Thanks for the message. I do not see that warning message. Imho we do not use any node-related code in the build actions.

[Andarix]

listingserver is in Node

[prissi]

The listserver runs independent of github actions. Actions are not suitable to run a server since there is a time limit. So nothing to worry, indeed.

[Matthew]

Thanks for the message. I do not see that warning message. Imho we do not use any node-related code in the build actions.

Thank you for the quick reply. This is an example of what I see:



Looking more closely it seems that it might relate to an Action that our workflow is calling? Something to do with uploading releases?

I found the issue about this warning in that Action's repo. It seems that the Action was updated to Node 16 in version 1.10. And in fact the latest version of the script is 2.5. So possibly we are running an outdated version of it. Our YAML file says:

name: Update binaries of Nightly Release
      uses: svenstaro/upload-release-action@v1-release

The discussion of that issue also mentioned that the Action has been forked here to deal with this problem, though the GitHub stars etc. suggest the fork has not proved very popular.

Hopefully this info will save some digging for anyone who understands GitHub Actions, which I don't.

[Dwachs]

Thanks! I changed the actions to not use the deprecate node stuff.

But the MacOS-build action also targets a deprecated system. Not sure about this.

[prissi]

MacOS builds with latest too, it seems.

[Dwachs]

The android build still fails with some linking errors

https://github.com/simutrans/simutrans/actions/runs/4317433415/jobs/7534494122#step:14:13697

Probably some (standard) library is not found.

[prissi]

No, this is very complicated. The fragile build system works up to Api level 29. Google wants at least 31 (soon 32), i.e. only support phone newer than three years ago or no listing in the play store. Also needs to use new build tools, but the syntax of calling clang has changed. This is however encoded somewhere deep inside the build system.

The proper way would be to start from scratch, i.e. download SDL2, freetype, libzstd, (libz and libpng are needed to build SLD2 anyway, I think) and then build them independent from the pelya patch. That would hopefully work also next year.

Unfortunately, my time to go on this endevour is very limited. Quick fixes doe not work, sicne google change the build system completely from ant to gradle to whatever now. Sicne any app has to provide all libs, it has to build them (why not lining statically then but enforcing individual shared libs?!?) and many other pitfalls.

It seems worse than apple ...

[Roboron]

I don't know if it helps, but I found that pelya's port has been updated in this fork https://github.com/n-ice-community/commandergenius (OTTD: https://github.com/n-ice-community/openttd-android)

Maybe you can find what you are looking for there...

[Roboron]

I've managed to fix the clang error by setting APILEVEL to 21 at project/jni/application/setEnvironment-armeabi-v7a.sh

=> https://github.com/Roboron3042/commandergenius/commit/c4645c9dcb05833512fceabf48b32dc6d7d40456


However, now it fails with:

Code Select Expand

src/simutrans/sys/clipboard_s2.cc:14:10: fatal error: 'SDL2/SDL.h' file not found
#include <SDL2/SDL.h>