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.

[emuslor (James Wilkinson)]

I'm good with the changes and with Kenneth being added as comaintainer.

[kenneth.f.cunningham@…]

Portfile replacement if desired

[kenneth.f.cunningham@…]

Portfile diff from 1.7

[raimue (Rainer Müller)]

For the build, the .py files would need to be patched with the correct interpreter. The installed scripts also have a shebang of #!/usr/bin/env python which will pick up any python and not necessarily the one it was configured for. This is especially important as this port seems to require pygtk, but no such dependency is added. There is no guarantee that the currently selected python is still the same as during configure or that pygtk is available on this version at all.

$ hatariui
Traceback (most recent call last):
  File "/opt/local/bin/../share/hatari/hatariui/hatariui.py", line 26, in <module>
    import gtk
ImportError: No module named gtk

However, even with pygtk installed, this launch script does not work. The hatari binary was only installed to ${applications_dir}/hatari.app/Contents/MacOS/hatari. Probably a symlink should be added to bin/ to be able to run it from the shell.

$ sudo port install py27-pygtk
...
$ hatariui
...
sh: hatari: command not found

[ken-cunningham-webuse]

Hey, thank you Raimue!

I appreciate your taking the time to check it out. Look at that -- I truly never guessed anyone would try to run the python GUI script hatariui from the command line if they installed the MacOSX GUI ... indeed, the port is not set up to be used that way. But it was there, so why not try it? Thanks for finding that.

The python gui script should not be installed at all if the MacOSGUI is being built, as it can never work. That's an upstream bug, but I might be able to rewrite their install script to delete that.

This port was coded to install using either the the MacOSX GUI, or the command line version. (variant commandlineapp), which installs the "hatari" executable into $prefix/bin. To get both at once you would have to build it twice, as it builds differently for each version of the executable. And people who can build the the MacOSX GUI (10.6+) get the MacOSX GUI by default, although they can override it for the command line version instead. 10.4 and 10.5 get the command line version only due to 10.6+ specific AppKit features.

Regarding the python version spec, yep, they shebang it, lazy bums. Alway have - the current version on macports, 1.7, does as well. For the tiny build script, this is not a very big deal as it's used very sparingly, deleted after the build, and the build script I rewrote to satisfy all python versions.

For a python GUI it could be important -- but there will be no python GUI in this port, just the MacOSX GUI, so maybe that's not an issue.

Still, it would be nice if they fixed it to use a specific python version someday.

Thanks again!

[ken-cunningham-webuse]

Deleted the (unnecessary) pythonui. It's not useable in the MacOSX GUI version, not needed for the command line version, and might conceivably cause some people trouble.

No references to python remain for any routine use. No python build scripts appear to be used during the construction of this app any longer.

[A few python debugging scripts get installed, to be used by people debugging hatari. I would imagine such people would know how to set their python version.]

[ken-cunningham-webuse]

portfile replacement - no python

[ken-cunningham-webuse]

Portfile diff from 1.7 - no python

[raimue (Rainer Müller)]

Committed in r153137 with slight changes.

I removed the revision 0 line. This is the default and usually not listed.

Sorry that I did not notice this before, but was there a good reason to switch to fetch.type hg instead of downloading the tarball? Downloads from VCS systems will not be mirrored, have no checksums for integrity, might not work behind proxies, and will not be kept locally. In case a rebuild is required, everything has to be downloaded again. Please only fetch from VCS if no other options is available. Therefore I switched back to the tarball download.

[ken-cunningham-webuse]

I think this ticket can be closed now as this was committed. -- K