Retro68: improve Docker support to enable builds with Universal interfaces

[mcayland]

Depends on: https://github.com/autc04/Retro68/pull/193

This PR follows up on my previous work at https://github.com/autc04/Retro68/pull/193 to generate a Docker image for Retro68, and adds support for builds with Universal interfaces. The motivation behind this is to provide the infrastructure required to allow CI builds from source for QEMU Mac Drivers (both 68K and PPC) which is a requirement for if binaries are to be distributed within QEMU itself.

As noted in the current README.md file, there is concern over the distribution of the MPW interfaces. The solution provided in this series is to provide a mechanism to dynamically generate the Retro68 headers from a MPW-GM.img.bin MacBinary DiskImage provided as either a file on the host or a remote URL. If the Universal interfaces are requested on startup by setting INTERFACESFILE=universal then the container startup sequence in entrypoint.sh looks like this:

• If the INTERFACESFILE variable is set to a URL, download it from the URL into the container
• Invoke ConvertDiskImage to decompress the DiskCopy image so it is usable by hfsutils
• Locate the Interfaces&Libraries folder within the image, and extract its contents
• Invoke the functions from interfaces-and-libraries.sh to link the Universal interfaces so that they are used instead of the in-built multiversal interfaces

The startup logic checks to see if the universal/RIncludes directory is empty on startup, and if so goes directly to linking the Universal interfaces to allow use of local caching without having to re-download the MPW-GM.img.bin file each time.

Finally this series updates README.md (see https://github.com/mcayland/Retro68/tree/feature/docker-build-universal#using-retro68-with-docker) to add a new section "Using Retro68 with Docker" giving examples showing how to perform multiversal or universal builds, both with or without caching.

[mcayland]

Okay I've repushed this rebased on current master with the rename of entrypoint.sh to docker-entrypoint.sh for you to look at. The same image has also been pushed to my personal ghcr.io repository so you can test it to see how the Universal Intefaces setup works as below:

$ export MPWURL=https://mysite.com/MPW-GM.img.bin   # (you can use the staticky.com URL for this)
$ docker run --rm -it -e INTERFACES=universal -e INTERFACESFILE=$MPWURL ghcr.io/mcayland/retro68

[autc04]

Do I understand correctly that switching back to Multiversal is not currently supported, i.e. one would have to recreate the container rather than just removing the envvar from the command line? (I wouldn't consider that a blocker though)

[autc04]

Throwing out some ideas for future improvements, definitely not within the scope of this pull request:

• streamline & document install-universal-interfaces.sh for use without docker
• ... we could get rid of the dependency on macutils
• helper scripts that are supposed to be used with the docker (or with any other installed version of Retro68, actually) should probably be installed to toolchain/bin
• install destination inside the docker should probably be something like /opt/retro68 or /retro68 instead of /Retro68-build/toolchian/

[mcayland]

Possibly? The aim of the docker-entrypoint.sh was to be as thin a wrapper as possible onto interfaces-and-libraries.sh with the extraction of the Universal interfaces handled by the new install-universal-interfaces.sh script. So I guess that once you're inside an image that was initially setup for Universal Interfaces you could re-run interfaces-and-libraries.sh to switch back to Multiversal interfaces?

[autc04]

Anyway, thanks a lot, I will merge this as soon as I see that nothing surprising happened during the build.

[mcayland]

Throwing out some ideas for future improvements, definitely not within the scope of this pull request:

* streamline & document `install-universal-interfaces.sh` for use without docker

* ... we could get rid of the dependency on macutils

* helper scripts that are supposed to be used with the docker (or with any other installed version of Retro68, actually) should probably be installed to toolchain/bin

* install destination inside the docker should probably be something like `/opt/retro68` or `/retro68` instead of `/Retro68-build/toolchian/`

Yes, that all sounds really great. I mainly tried to implement the functionality to use Retro68 within CI making as few changes as possible (hence the path being /Retro68-build/toolchain to match the original docker image rather than changing it). However now the initial support is merged, it makes it much easier to develop and test these types of changes.

[mcayland]

Fantastic! Thank you once again for all your hard work maintaining Retro68.

[mcayland]

@autc04 FYI we've now completed the first integration of the Retro68 docker image into a github action within the classicvirtio repo at https://github.com/elliotnunn/classicvirtio (this repo contains a series of experimental Classic MacOS drivers for 68k and PPC to allow access to QEMU's virtio devices). There is plenty of active discussion on libera.net IRC channel #mac68k if you are interested to follow.

[autc04]

Thanks for the info!