From 3269a008fe146571c4f5443acb0437e7e987353f Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Fri, 15 Oct 2021 15:24:48 +0300 Subject: added Mac OS nightly builds (#8) * Only x86_64 builds are supported for the time being. They have been tested on Mac OS 10.15 (Darling) and 11 (thanks to @dertuxmalwieder). * Curses glitches remain on Mac OS as reported by @dertuxmalwieder. Under Darling with a Linux terminal emulator, everything looks as it should. * We don't build AppBundles or pkg installers but instead came up with a rather ideosyncratic way of packaging: The packages are tarballs of the installation tree with all dependant libraries added under /usr/local/lib/sciteco - thanks to dylibbundler. The archives are supposed to be unpacked into the UNIX tree root (`tar -C / -xf sciteco.tar`) and it will be necessary to "de-quarantine" all the binaries. Details will be documented in the wiki: https://github.com/rhaberkorn/sciteco/wiki/Mac-OS-Support * Perhaps we will also ship an installation script (TODO). * AppBundles would have the disadvantage that they cannot be directly installed into $PATH. On the other hand, this would be relatively easy to do afterwards. An AppBundle would need certain code adaptions for Mac OS, though. * Gtk+ builds are not yet supported as I cannot test them with "Darling". * All Nightly Build artifact names now mention the target architecture. * build Win32 nightly builds with windows-2019 * May improve compatibility slightly in the future as we should always build our binaries on the oldest possible system. * Does not change anything currently since windows-2019 == windows-latest. * CI still uses windows-latest and may therefore one day switch to windows-2022. * updated README --- .github/workflows/nightly.yml | 80 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 7 deletions(-) (limited to '.github/workflows/nightly.yml') diff --git a/.github/workflows/nightly.yml b/.github/workflows/nightly.yml index 1f66fab..a03a400 100644 --- a/.github/workflows/nightly.yml +++ b/.github/workflows/nightly.yml @@ -50,11 +50,80 @@ jobs: - name: Archive Debian/Ubuntu Packages uses: actions/upload-artifact@v2 with: - name: SciTECO nightly packages on ${{ steps.date.outputs.date }} (${{ matrix.os }}, ncurses and GTK+ 3) + name: SciTECO nightly packages on ${{ steps.date.outputs.date }} (${{ matrix.os }}, x86_64, ncurses and GTK+ 3) path: debian-temp/*.deb + macos: + runs-on: macos-10.15 + + steps: + + - name: Git Clone + uses: actions/checkout@v2 + with: + submodules: true + + # NOTE: macOS already ships with ncurses and groff. + # The system libncurses has turned out to be buggy, though (keypad() does not work). + # However, it does work on real Mac OS systems, I was told. + # Linking in our own ncurses should also be more portable in case + # the system libncurses ABI breaks. + # However, Homebrew installs ncurses as a keg and it will refer to a + # non-standard $TERMINFO. This could be worked around. + - name: Install Build Dependencies + run: brew install autoconf automake libtool glib dylibbundler + # FIXME: It would be nice to build universal arm64/x86_64 binaries, + # this apparently requires two separate build runs and a following merge + # using `lipo -create`. In this case we could just as well build two + # separate packages. + - name: Configure Build + env: + # Make sure we don't pick up GCC by accident. + CC: clang + CXX: clang++ + # FIXME: Once there is an --enable-lto, we should use that. + CFLAGS: -O3 -flto + CXXFLAGS: -O3 -flto + LDFLAGS: -flto + # Uncomment if you want to build against the Homebrew-installed libncurses. + #PKG_CONFIG_PATH: /usr/local/opt/ncurses/lib/pkgconfig + # NOTE: This will not result in a fully statically-linked binary, + # but the more we get rid off, the better. + run: | + autoreconf -i + ./configure --with-interface=ncurses --enable-static-executables + + - name: make + run: make -j 2 + # NOTE: The test suite must be run in verbose mode because if it fails + # we won't be able to analyze testsuite.log. + - name: Run Test Suite + run: make check TESTSUITEFLAGS="--verbose" + + - name: Package + run: | + make install-strip DESTDIR=`pwd`/temp-install + # There are libraries we cannot link against statically. + # We ship them in /usr/local/lib/sciteco so as not to cause collisions with system + # libraries or libraries installed via Homebrew. + # System libraries are considered to have stable ABIs and + # are not currently bundled. + # FIXME: Is this really true for libc++? + dylibbundler -b -x temp-install/usr/local/bin/sciteco \ + -cd -d temp-install/usr/local/lib/sciteco -p @executable_path/../lib/sciteco + tar -C temp-install -cf sciteco.tar . + + - name: Get Current Date + id: date + run: echo "::set-output name=date::$(date +'%Y-%m-%d')" + - name: Archive Mac OS Distribution (ncurses) + uses: actions/upload-artifact@v2 + with: + name: SciTECO nightly build on ${{ steps.date.outputs.date }} (Mac OS, x86_64, ncurses) + path: sciteco.tar + win32-curses: - runs-on: windows-latest + runs-on: windows-2019 defaults: run: @@ -132,14 +201,11 @@ jobs: path: temp-bin/* # NOTE: There is a lot of redundancy with win32-curses. - # However we link the Curses version statically, while Gtk+3 cannot be + # However the Curses version may be linked statically, while Gtk+3 cannot be # linked statically on Windows (at least MSYS does not provide # static libraries) and would draw in libglib, libintl, libiconv etc. anyway. - # On the other hand we currently have to package all sorts of libraries only - # for gspawn-win32-helper-console.exe - if this situation persists, we can - # just as well unify the two jobs. win32-gtk: - runs-on: windows-latest + runs-on: windows-2019 defaults: run: -- cgit v1.2.3