Also, refactor CI configs to only specify the Python 3 and Perl versions
in one place, so we don't have to multiple lines in the config file.
Additionally, add checks to make sure the Homebrew Python 3 version
matches the configured one, so we will have a failed build and be
notified this way instead of silently building against an old version of
Python in CI, which would still work as GitHub CI has older versions of
Python installed.
Note that if https://github.com/vim/vim/pull/12032 is merged, this will
be less painful in the future as stable ABI should mean we don't have to
care as much about the exact Python version.
Recent Vim builds introduced the use of clock_gettime(), which on macOS
was only introduced in 10.12. In Vim, we added a configure check to
detect its existence (https://github.com/vim/vim/issues/12242) but it
only works to detect the build-time environment. For MacVim builds we
build on new machines but deploy on old machines by using
MACOSX_DEPLOYMENT_TARGET=10.9 when building. This means that the
configure script will detect clock_gettime() exists and includes it, but
at runtime the app will crash when running MacVim (legacy builds) in
10.9-10.11.
To fix this, add explicit checks to make sure we undef
HAVE_CLOCK_GETTIME if deployment target is below 10.12. Unfortunately
there isn't really a way to detect such things automatically in a
configure script as it requires knowledge of historical releases.
Use newer formats for creating the DMG file for distributing MacVim.
APFS has been supported fully since macOS 10.13, and from testing it
extracts faster than HFS+.
LZFSE (ULFO format) is newer than zlib/DEFLATE (UDZO format) and also
decompresses faster as well from testing. Note that there is a newer
compression scheme using LZMA (ULMO format) but it is only supported in
10.15+ which is too high for us as non-legacy builds need to target
10.13+. Also, from testing, the newer LZMA yields smaller files, but
takes more time to decompress than LZFSE.
Also, keeping using the old formats (HFS+/zlib) for legacy builds since
they need to work on 10.9, which don't support the newer formats.
Problem: CI: check in sound-dummy module may throw an error.
Solution: Check whether apt-cache can show the package description.
(Christian Brabandt, closes#12390)
In the CI setup, xcode-select is only called after the packages have
been set up, but during setup we actually need to build the packages
from source to have the correct deployment target linked correctly. This
means we could potentially be building with the wrong configuration
(e.g. when building for 10.9 legacy builds, we could be using an Xcode
version that's too new for that) when building gettext/libsodium. This
is compounded by the fact that our GitHub Action cache key for the
libraries only include the formula, but not the active Xcode version
itself so a cache could be propagated for a while until suddenly things
break.
To fix this, first make sure we do Xcode configuration early on in the
build, and to properly use the Xcode version as part of the cache key.
This way, when Xcode version changes, we will invalidate the cache and
rebuild gettext / libsodium with the correct configuration and if that's
wrong we will immediately fail the build instead of using old stale
caches.
Also, bump Xcode from 14.1 to 14.2 in CI.
GitHub has a security tab that allows repos to manage their security
policy so it's not a bad idea ot be explicit in expectations. The policy
is to either use GitHub's builtin reporting system, or email MacVim's
team (in case that's the preferred method or the reporter does not want
to have a GitHub account). The most important thing is to not use the
public GitHub issue filing.
I don't think this will be used too much, but given that MacVim (and
Vim) can read arbitrary file, there is always a potential for a security
issue to pop up.
With the release of Homebrew 4, auto-update is supposed to be more
efficient now. By removing the HOMEBREW_NO_AUTO_UPDATE env var from CI,
this will make sure that all the packages that we link to in CI will be
up to date instead of whatever just happens to be installed on the CI
environment which can sometimes fluctuate.
Previously, when configured with `--disable-sparkle`, the
Sparkle.framework would still get linked and copied into the app bundle.
This is because Xcode doesn't have an easy way to disable individual
build phase. We would either have to make a new build target, or
dynamically patch the project file in order for that to not happen.
Package managers like Homebrew and Nix have to either manually delete
the framework as a post-build step, or manually patch the pbxproj file
as a pre-build step to make sure the framework never got linked/copied.
Also, when building MacVim on macOS 10.9-10.12, where Sparkle 2 is not
supported, even if you build with `--disable-sparkle`, the app still
wouldn't run since Sparkle 2's framework still got copied into the app
and on launch the OS will detect that it's not compatible with the OS
version.
To fix this, just add a new env var and have the build cleanup script
delete the entire Sparkle.framework as a post-build step, if
`--disable-sparkle` was previously configured.
One thing to note is that currently, even with this, the MacVim binary
still has a weak linking dependency to the non-existent
Sparkle.framework (can be seen by doing `otool -L
MacVim.app/Contents/MacOS/MacVim`) but it should be fine. A proper way
to fix this is to manually link Sparkle instead of letting Xcode do it
for us, but considering that this is a relatively niche use case, and it
still works regardless, there isn't a pressing need to do so.
Also, add CI check to make sure when `--disable-sparkle` is used, the
actual MacVim binary has 0 references to Sparkle symbols. This makes
sure that removing the Sparkle.framework from the app bundle is actually
safe.
Add CI test to confirm desired Vim features like +sound / etc exist.
Smoketest also checks for libsodium now by trying to set xchacha20
cryptmethod which can only succeed if sodium is enabled. Also make sure
it's actually checking the scripting language bindings are working
properly. Previously for some reason it wasn't checking the print
results.
Sparkle 2:
Seems like older Xcode versions (before 12.5) have problems signing
frameworks that only have a Versions/B but not a Versions/A folder.
Sparkle 2 moved to only having Versions/B which is causing code sign to
fail on build step. Just fix this issue by disabling Sign on Copy for
Sparkle.framework. We don't really need it because it already comes with
an ad-hoc signature anyway, and for publish we have a custom signing
script (sign-developer-id) to do manual signing.
Also, fix CI to use Sparkle 2 again for old Xcode (11.7) builds to test
this working. Previously we made it use Sparkle 1 because we didn't work
around this issue, which was kind of a hack.
For Sparkle 2, also add a `cleanup-after-build` script to remove the XPC
Services folder in the framework. Sparkle dev added this to the bundle
for sandboxed apps but non-sandbox apps don't really need it and it's
recommended by Sparkle to remove them, so we unfortunately need to
manually do it as a post-build step.
Fix#1335
Signing / notarization scripts:
Make sure to sign Sparkle 2 binaries in `sign-developer-id`. Also, seems
like the "--deep" flag in codesign is now deprecated as of macOS 13, so
just stop using it and manually sign all the relevant binaries
explicitly.
For notarization script, the current behavior doesn't correctly detect
failure as `xcrun notarytool submit` always exits with 0 even if the
submission failed. Add logic to manually query whether the submission
succeeded. If failed, print out the logs for easier diagnosis, and
exits with -1 so it will block progress.
Add a configure flag to set the USE_SPARKLE_1 ifdef flag. In CI legacy
builds, we will relink the symlink to point to Sparkle_1.framework and
also call that configure flag so the code will build.
SDK for the new macOS 13 (released as part of Xcode 14.1) increased the
minimum deployed OS from 10.9 to 10.13. Since we still want to support
a minimum OS requirement of 10.9, while building against the latest SDK
to get the most up-to-date features, we have to split the build process
to build two separate binaries. A regular MacVim that targets the macOS
13 SDK (with min OS target 10.13), and a "legacy" MacVim that targets
the macOS 12 SDK (with min OS target 10.9).
Change the GitHub Action CI config to have two separate matrix entries
that publish, with one having a "legacy" flag set, which will use the
older version of Xcode and the correct env vars set. It will also only
build for x86-64 (no arm64) since currently all Apple Silicon hardware
can run the latest versions of macOS and would have no need to run
legacy builds.
Also, fix some scripting issues:
- fix Python 2 library path set incorrectly
- Update Perl to 5.30 from 5.18, as 5.18 is no longer installed in macOS
13. We could potentially change Perl to use the Homebrew version
instead similar to how Python and other scripting languages are done
but for now this works fine (except it won't work on older macOS
versions). Perl is a rarely used language for Vim plugins.
See https://github.com/macvim-dev/macvim/discussions/1288
