hatari update to 1.9

[kenneth.f.cunningham@…]

Suggestion for hatari update to 1.9, if accepted by maintainer.

Enhancements:

1. add in fixes for MacOSX GUI (now the default for 10.6 and above, but command line version remains available)
2. add SDL2 option for 10.6+
3. add winuae option, with fix for gcc compiler error

Fixes:

1. fix python code in case python3 preselected by user. python code back-tested to 10.4.
2. fix gcc winuae compilation error

Testing:

1. GUI version tested 10.6 with LibCxx upgrade, 10.7, 10.11
2. command line version tested 10.4 PPC/Intel, 10.5 Intel, 10.6 with LibCxx upgrade, 10.7, 10.11
3. winuae compiles and runs on all systems
4. universal works on Intel 10.6+, not tested lower

I'm OK to be listed as co-maintainer if OK with original maintainer.

[kenneth.f.cunningham@…]

python3 fix for files/

[larryv (Lawrence Velázquez)]

Replying to kenneth.f.cunningham@…:

1. fix python code in case python3 preselected by user. python code back-tested to 10.4.

What is the build doing with Python? It really should not be using ${prefix}/bin/python at all. Patching the build to be compatible with Python 3 is glossing over an actual problem with the port.

[kenneth.f.cunningham@…]

Thanks, Lawrence,

I finally concluded (as per the mailing list discussions and with your help and that of others) that the cmake build script (in all versions of hatari, including the existing 1.7 version on macports now) has skipped the part about prefacing python calls with ${PYTHON_EXECUTABLE)/path/to/script.py. They just call /path/to/script.py, and let 'shebang' figure it out with the internal shell setup cmake uses.

And because cmake doesn't inhale environment variables, and there seems to be no way to set the shell call environment variables that the cmake shell will honour that I can discover after several days of looking, there seems to be no way to modify the shebang python target cmake calls. I could have monkeyed with the path and forced it to python27 as we discussed, but this seemed less desirable as per our previous discussion. The proper way is to rewrite the cmake build script with ${PYTHON_EXECUTABLE)/path/to/script.py

Upstream will someday, maybe, fix the python calls in the build script. Or perhaps I might fix it for them at some point, for their next release (whenever that might be). I have a couple of cmake reference tutorials on the go just now, but like Ryan pointed out, it's a bit of challenge getting the hang of it.

In the meantime, the fix here will makes the existing python script compatible with all known python versions back to Tiger, and probably robust for at least all python 3.x versions that might show up, and it's certainly better than the existing port's python script that fails if the user has python 3.x selected.

So I guess it's kind of a question of "better" being acceptable, vs "perfect".

Hatari 1.9 is the last released version, and I'm not aware at present of an imminent new release that might fix this.