diff options
| author | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2021-10-15 15:24:48 +0300 |
|---|---|---|
| committer | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2021-10-24 01:47:50 +0300 |
| commit | 3269a008fe146571c4f5443acb0437e7e987353f (patch) | |
| tree | afe74ee6588b2efa23735ebd16701ffa185f3733 /src | |
| parent | aa00bf10d986bf3a022c33be1cb79fdd4dadf438 (diff) | |
| download | sciteco-3269a008fe146571c4f5443acb0437e7e987353f.tar.gz | |
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
Diffstat (limited to 'src')
| -rw-r--r-- | src/memory.c | 7 |
1 files changed, 3 insertions, 4 deletions
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. |