Cross compiling: either MacOS or Windows cross-compiling will fail

[VOLVO]

I have been unable to join die to incorrect revision for x64 .exe and crash immediately after joinging for using the x86 .exe. Any idea what did I do incorrectly?

[SuperTimo]

I had the same problem yesterday

I'm having the same problem and had the same yesterday. It seems that the 64bit .exe isn't being updated as it's date modified was 16th August.

[jamespetts]

I have now fixed this issue and am in the process of recompiling now.

[freddyhayward]

I have now fixed this issue and am in the process of recompiling now.

This has caused the macOS build to fail according to the github CI.

[jamespetts]

This has caused the macOS build to fail according to the github CI.

The problem was caused by a change pushed by Ceeac a few days ago. I reverted this change to allow nightly builds to function, but this now seems to be incompatible with MacOS builds.

I need to understand more about why Ceeac made the change that he did so as to allow us to have code that will compile either on the Windows or the MacOS cross-compiler.

I will split this topic into the Simutrans-Extended development section so as to allow this discussion to continue in a more suitable place.

[freddyhayward]

I created a pull request (https://github.com/jamespetts/simutrans-extended/pull/255) that hopefully fixes this temporarily before Ceeac can explain what exactly his change does - mine just uses a different include for windows. Can you test compilation on Wndows for that branch?

edit: Ceeac, is it possible to add Windows builds to the CI?

[prissi]

Windows builds in github actions are not easy to set up, even compared to cross-compiling under Linux. Imagine you have to set up a windows development environment using all the right libraries and includes without a single mouseclick. I played around for two evenings but found it very difficult and did not want to waste my time there.

[ceeac]

edit: Ceeac, is it possible to add Windows builds to the CI?

I added mingw builds in the mingw-ci branch. (I have not yet opened a pull request because the work is not finished.)

About the build failures, I believe these were caused by sdl2-config not being installed on macOS so a different include path was used. So I think having #include "SDL.h" instead of #include <SDL2/SDL.h> is fine if sdl2-config is installed on macOS. But I have not yet investigated this thoroughly.

[jamespetts]

Thank you to Freddy for the fix for this, which I incorporated yesterday; this is most helpful.

[TurfIt]

The fix applied is technically incorrect as the issue has nothing to do with Windows vs. non.  "#ifdef _WIN32" *must* be only be used for Windows specifics, not compiler issues - ie. msvc vs mingw. use "#ifdef _MSC_VER" instead.

The SDL2 devel packages all put the includes under /include/SDL2/* except for MSVC which just gives you the files in the root of the .zip. If MSVC is configured to look in /include for system includes, and you manually create /include/SDL2/ and unzip the library there, #include <SDL2/SDL.h> will work fine.   On Linux / MinGW / MacOS, specifying to use sdl2-config in config.default adds /include/SDL2/ to the search path, hence #include "SDL.h" will work, and <SDL2/SDL.h> work also since SDL2 is under /include/ which is searched by default. But if sdl2-config is not used (I couldn't make it work on older MacOS in the past), only #include <SDL2/SDL.h> works.   (aside: the current MSSY2 MinGW packages have a mangled sdl2-config that prevent static linking, some manual fixes are needed - hopefully someday whomever made that SDL2 MSSY2 packages sorts it out...)

IMHO, keeping #include <SDL2/SDL.h> is more flexible - can use sdl2-config, or not.  With #include "SDL.h", one must use the -config, or edit config.default to add include/SDL2 to the search path manually. But the choice is yours.
For MSVC - I don't use, it sure seems to attract issues with libraries......  but please *never* use #ifdef _WIN32 like that - it just breaks MinGW compiling.

[ceeac]

In Standard, simsys_s2.cc includes <SDL2/SDL.h> however the approach of just including <SDL2/SDL.h> or <SDL/SDL.h> does not work for sdl_sound.cc which is used for both SDL1 and SDL2.

[TurfIt]

SDL2 makefile uses sdl2_sound.cc which #includes <SDL2/SDL.h> and works fine, but does appear missing from Extended... getting standard's fix commits fully applied to Extended really should be a top priority...
SDL1 backend is considered deprecated - while still fastest for some systems, others choke badly (MacOS and some Linux window managers), so not maintained. Neither is the library itself.
sdl_mixer backend was never created/updated for SDL2.

[jamespetts]

I wonder whether it might be worthwhile deprecating SDL1 support for Simutrans in the circumstances? On the face of it, it would seem to impose an unreasonable maintenance overhead to retain support for a deprecated library.

As to merging from Standard being the top priority, in terms of what will actually affect players' experience of the game, achieving game balance, and implementing the balance critical features, is likely to have a significantly higher impact, although it would certainly be good to get up to date with Standard.

[ceeac]

I'm in favour of removing SDL1 support. I believe we can also remove the Allegro and OpenGL backends, since the former is only for OSes which Extended does not support due to the C++11 requirement, and the latter has already been removed from Standard (and also requires SDL1, IIRC). I'll make a pull request shortly.

[jamespetts]

I'm in favour of removing SDL1 support. I believe we can also remove the Allegro and OpenGL backends, since the former is only for OSes which Extended does not support due to the C++11 requirement, and the latter has already been removed from Standard (and also requires SDL1, IIRC). I'll make a pull request shortly.

Excellent, thank you; I shall await the pull request.

[ceeac]

Pull request submitted: #263. I opted for changing the SDL2 includes to #include <SDL2/SDL.h> and likewise for SDL2_mixer so the Visual Studio include directories probably need to be updated if the build fails.

[prissi]

SDL1 is incompatible with non-english input, i.e. any extended two byte character set. SDL2 has excellent IME support, even easier to use than the native windows one.

r9184-9184 are adding SDL2 64bit github support for windows standard even including the automatic pakset installer. Maybe you can use this for extended too.

[VOLVO]

It seems that it has happened again, the 64 bit version is incompatible to the version bridgewater-brunel server is hosting

[Matthew]

It seems that it has happened again, the 64 bit version is incompatible to the version bridgewater-brunel server is hosting

I was able to use today's Windows version to connect to Bridgewater-Brunel without difficulty. But I was using the -load net:.... parameter, so perhaps that overrides version incompatibility?

[jamespetts]

Ceeac - thank you for your work on this. Before I merge this, can I confirm that this is tested and working for Linux builds, Linux to Windows cross-compile builds and command line server builds?

[VOLVO]

I was able to use today's Windows version to connect to Bridgewater-Brunel without difficulty. But I was using the -load net:.... parameter, so perhaps that overrides version incompatibility?

If you are using 32 bit version it's because the 32 bit version program is the correct version while the 64 bit isn't

[ceeac]

Ceeac - thank you for your work on this. Before I merge this, can I confirm that this is tested and working for Linux builds, Linux to Windows cross-compile builds and command line server builds?

Yes, see here. I have also tested the generated Windows and Linux binaries manually to verify that they start up. But if your cross-compiling setup is different, I cannot guarantee it works (though it should).

[jamespetts]

Yes, see here. I have also tested the generated Windows and Linux binaries manually to verify that they start up. But if your cross-compiling setup is different, I cannot guarantee it works (though it should).

Splendid, thank you. I have now got this to work. I had to add a new preprocessor directive for the alternative include directories for my MinGW cross-compile build on Linux, but this should not affect any platform build that does not explicitly use this preprocessor directive.

Thank you for this.