dcpomatic/cscript, branch v2.15.118 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.15.118 2021-01-07T11:06:42Z Update lwext4 for build fix so that its arm64 library is relinked 2021-01-07T11:06:42Z Carl Hetherington cth@carlh.net 2021-01-07T11:06:42Z urn:sha1:4493afeec215e67209cdc05c39d6e3a30c3df3f4 correctly. Otherwise gatekeeper refuses to run DCP-o-matic. Seems over-complicated to use SDK-specific subdirectories. 2021-01-05T17:09:25Z Carl Hetherington cth@carlh.net 2021-01-05T17:09:25Z urn:sha1:7c4d7ce5b9408a68ddf7c6122339ee472341cad7 Make a universal binary containing x86_64 for SDK 10.9 and arm64 for SDK 11.0. 2021-01-05T13:20:34Z Carl Hetherington cth@carlh.net 2021-01-05T10:04:13Z urn:sha1:74c008c57fb48291c6701b9b1ab24eb3fc90840f Another linux build fix. 2021-01-04T14:17:43Z Carl Hetherington cth@carlh.net 2021-01-04T14:17:43Z urn:sha1:8f4b45d7e3c83d390fb77728f84d6984d0650a05 Fix linux build broken by arm64 changes. 2021-01-04T13:23:59Z Carl Hetherington cth@carlh.net 2021-01-04T13:23:59Z urn:sha1:0e571479e7e19f41f2b17335d7dd4cb78141c5fb Fix macOS image construction stuff for the 64-bit only, 10.9-or-higher world. 2021-01-04T09:48:59Z Carl Hetherington cth@carlh.net 2020-12-30T11:32:27Z urn:sha1:96a468738d4619745fdaf252f64cd06ca8491a96 Now we can build: - arm64/x86_64 universal builds against 11.0 - x86_64 thin builds against 10.9 Which means no more support for 32-bit macOS (which I think excludes macs made in 2011 or earlier) or for 10.8 (Mountain Lion) or earlier (released in 2012 and possibly end-of-lifed in October 2015). Support for arm64 macOS builds. 2021-01-04T09:48:59Z Carl Hetherington cth@carlh.net 2021-01-01T21:16:21Z urn:sha1:c39b290f02f49b68a3eb928fe1109cc7f6bf59eb Update dependencies for arm64 builds. 2021-01-04T09:48:59Z Carl Hetherington cth@carlh.net 2020-12-23T16:10:26Z urn:sha1:c6c5e30d75800031b9ad06015f271865e148e538 Remove support for macOS 32-bit builds. 2021-01-04T09:48:59Z Carl Hetherington cth@carlh.net 2020-12-23T16:05:01Z urn:sha1:ba152e6c12018f6ff21d760b065b552f09246752 Pass fonts from content around as FontData. 2020-12-22T01:37:53Z Carl Hetherington cth@carlh.net 2020-12-20T22:41:52Z urn:sha1:ddcd4f3ba0af3e9d49dbb68127317cd0d871a248 i.e. as a block of memory rather than a file. Also, get the fonts from the decoder rather than the content. Together, these changes allow us to use fonts from SMPTE DCPs added as content. Before, fonts would be messed up in those cases (#1885).