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

1 files changed, 73 insertions, 7 deletions

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: