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 --- src/memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'src') diff --git a/src/memory.c b/src/memory.c index 5958224..2edec46 100644 --- a/src/memory.c +++ b/src/memory.c @@ -437,10 +437,9 @@ teco_memory_get_usage(void) /* * Practically only for Mac OS X. * - * FIXME: Benchmark whether polling in a thread really - * improves performances as much as on Linux. - * FIXME: There is no malloc_trim() natively on Mac OS - can - * we recover from OOMs? + * NOTE: Running in a dedicated polling thread does indeed + * improve our performance significantly. + * * FIXME: We cannot simply overwrite weak malloc() functions * like on Linux since this does not affect shared libraries * unless $DYLD_FORCE_FLAT_NAMESPACE is set. -- cgit v1.2.3