- v2 will be unavailable from the end of June 2024
- v4 can be up to 98% faster than previous versions according to
[Github's
notification](https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/)
This PR only changes the version number, and I'm submitting it to see if
it works.
It is possible that further changes are necessary, as there were some
[breaking
changes](https://github.com/actions/upload-artifact?tab=readme-ov-file#breaking-changes),
but I don't think any of them apply to ares.
Testing:
- See if CI passes
- See if warnings regarding using v2 of `upload-artifact` and
`download-artifact` are gone (There will still be other warnings
regarding `checkout` and `cache`)
- (Optional) Compare times for the tasks using `upload-artifact` and
`download-artifact` with previous CI runs
#1463 renamed the `macos` build to `macos-latest` and introduced
`macos-compat`. We need to address the rename in the release workflow. I
believe this PR accounts for every use of the package name. Also adds
macos-compat to the release (for now).
Co-authored-by: jcm <butt@butts.com>
This PR does a few things:
- Updates ares to create macOS builds with the latest SDK. After
65264090b0
there are no longer any outstanding issues doing so. Importantly, we use
Xcode 15.2, since prior versions have issues with weak linking.
- Adds `macos-compat` to CI as a compatibility build that maintains
macOS 10.9 to 10.13 compatibility. The `macos-latest` runner will target
10.13 and above. The only difference with this build is the SDK version
used to build it (Xcode 13.4); macOS weak linking handles the rest.
- Increments the MoltenVK version to 1.2.7. The version ares was
building required a Python library `distutils` that is no longer
trivially available with newer Python versions.
- Refactors the `xcode-select` usage reserved for GitHub Actions out of
the SDL script and up to the top level, before any dependency scripts
are run. This is just tidying up.
- Improves the librashader build script warning to specify that you need
to add a target with the nightly toolchain to build librashader (from
@rasky)
- Unbreaks the build.
This PR has been tested and verified to build in a local branch, but to
be safe, it would probably be good to run it here as well.
Co-authored-by: jcm <butt@butts.com>
### Description
Adds SDL (properly) to Mac builds.
This time, it has been added as a fully fledged optional dependency in
`thirdparty`, à la MoltenVK, and built from source before ares. We build
from source because brew installations are both single-architecture and
not fully portable.
The .dylib is copied inside the app bundle when linking, at the same
stage as MoltenVK.
The initialization of `ares.dylibs` has been moved from ares's Makefile
to the `desktop-ui` Makefile so that it's initialized when building
ruby, which it wasn't previously.
The SDL build is also added to CI, with the same caching methods as used
for MVK.
### Relevant Details
`HEAD` points at SDL 2.28.5 currently, which is the most recent stable
release. This should probably be periodically incremented as
appropriate.
~~SDL is currently built with the macOS deployment target of 10.13.
While SDL's minimum supported macOS version is 10.11, ares CI is using
Xcode 14.2, which has a minimum deployment target of 10.13. I am
currently testing to see if I can get the deployment target lower
without breaking other parts of ares's CI.~~ resolved, per below; SDL
supporting 10.11 is built + bundled.
### Testing
This has been tested to build properly locally and via GitHub CI. The
.dylib is packaged inside the bundle correctly and SDL functions
correctly in my testing, even if the user does not have SDL installed
elsewhere on their system.
This is seeking tests from other Mac users, especially on older
operating systems, to verify that SDL works correctly there.
Co-authored-by: jcm <butt@butts.com>
Disable "fast fail" so jobs will run to completion even if others fail.
The workflow as a whole will still fail, but the jobs that succeed will
produce downloadable artifacts.
Secondly, allow the "macOS: Import Certificate" step to fail on forks.
This allows CI to function on forks without any other setup, though the
produced macOS builds won't run actually run unless you re-sign them.
The latest macOS runner updated the version of python to 3.12.0.
This removes the deprecated distutils core module, requiring the "setuptools" package to be installed to provide it.
distutils is a dependency of MoltenVK.
While I am happy we did the work to support this, having multiple
build systems does make it harder for contributions to be made
We can restore msbuild CI tests once (if) we eventually switch
to cmake.
- Because clangarm64 is now a default enabled package source, there is
no need to edit pacman.conf.
- Because there is no need to edit pacman.conf, there is no need to sync
the package database.
- Because there is no need to sync the package database, there is no
need to update the initial set of installed packages to prevent
version mismatches.
- Install the "clang" package in favor of the "toolchain" package group
as none of the extra packages are needed by ares.
Two things are making this a bit more complicated than it ought to be:
- The msys2 clangarm64 package repository is not enabled by default
because it is still considered 'experimental'
- Cross-compiling requires that you manually override the runtime
library directory for the 'builtins' lib to be located
Both of these issues are known and should be addressed eventually.
This change upgrades GCC from the version preinstalled by GitHub Actions
(8.1.0) to the latest MSYS2 version (10.3.0). It also adds a
Windows/Clang build configuration, though the release job still
grabs the GCC build.
Luke Usher