dcpomatic/platform/osx/make_dmg.sh, branch fix-tests

Build with an ffmpeg that includes libdav1d.

2022-02-17T08:59:26Z

Use different names for the 10.6 (thin) and 10.9 (universal) DMG files.

2022-02-07T20:55:35Z

Fix .dmg naming yet again; sed was breaking the $? check.

2022-01-18T21:07:25Z

Remove v that snuck into DMG filenames.

2022-01-18T13:04:33Z

Fix incorrect git command when getting the version with an exact tag.

2022-01-18T10:01:35Z

Fix versioning of .dmg filenames.

2022-01-17T17:49:08Z

Now we use a tag if there is one at the commit we built, otherwise -.

Fix inexplicable change to dylib paths with new VM.

2021-12-18T10:16:45Z

After re-creating the macOS build VM, suddenly liblwext4 ends up linked as @rpath/liblwext4.dylib which breaks the DoM make_dmg script. I can only guess this is due to me installing a newer CMake.

Fix old mac (single-arch) build.

2021-07-24T20:35:59Z

Make white/black versions of server icon.

2021-06-25T19:58:38Z

Fix relinking in make_dmg.sh

2021-06-02T08:27:58Z

c432ef98c4cf3b2bda32734983eec3b42b8c3d1e completely broke the relinking of libraries using install_name_tool by only doing it for the x86_64 part of the binaries. This commit fixes that, and also does some tidy up that happened while trying to debug the error. The main cleanup is that --deep is no longer used with codesign, rather we sign all the executables ourselves manually. Various Apple forums suggest that --deep is a Bad Idea for reasons that aren't really clear. For reference, after spending days trying to debug the Gatekeeper refusal to start DoM the way to reveal the problem was: 1. start a clean VM (there are caches everywhere, so once a failure has happened you are even less likely to get any useful logging on the second failure). 2. open "Console" on macOS; logs are written to un-greppable places so you have to use this to see everything. 3. click "start streaming"; I don't know if this step is necessary. 4. put a search term in the search box (e.g. "dcp" for this) 5. start the thing that is not working. And remember that otool without `-arch` on a fat binary will only really operate / look at the first? native? architecture, so if you have an x86_64/arm64 binary and the arm64 parts are wrong you won't see anything about that with `otool -L`, only with `otool -arch arm64 -L`