aboutsummaryrefslogtreecommitdiffhomepage
path: root/.github
AgeCommit message (Collapse)AuthorFilesLines
2025-03-22build nightlies on Ubuntu 24.04 as wellRobin Haberkorn2-2/+2
* Also run CI on 24.04. * The Ubuntu 20.04 runner is deprecated soon until 1. April 2025, but for the time being we keep supporting it as well.
2025-03-16CI: fixup - CFLAGS should not expand to "false"Robin Haberkorn1-2/+2
2025-03-16CI: perhaps fixed address sanitizingRobin Haberkorn1-4/+9
It can be done only under ncurses, as Gtk results in many false positives. Also, try to use it on GCC and Clang. It didn't work with GCC on FreeBSD, but perhaps it will work on Ubuntu.
2025-03-16CI: enable address sanitizer when building with ClangRobin Haberkorn1-1/+3
As I cannot run the test suite with Valgrind in Github runners, this should still catch some memory bugs during test suite runs.
2025-03-03rename sample.teco_ini to fallback.teco_ini and mung it by defaultRobin Haberkorn1-2/+2
* After installation, SciTECO will therefore start into a more userfriendly mode even if the user does not create a custom ~/.teco_ini. It is hoped that this will scare away less of new users, who are not willing to read through all of the documentation. Still, users are warned in the absence of ~/.teco_ini. This warning however, might not be immediately visible, especially not when running gsciteco without an attached console. (This will change once I redo the UI and allow a number of messages to be queued in the message area.) * Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini, but that would require installing it into $SCITECOPATH. * Since the fallback profile will now be munged automatically on a wide range of systems, we set up xclip only when detecting X11 ($DISPLAY is non-empty). E.g. when running under Wayland or the Linux console, you still won't get the clipboard registers, which is probably better than having the clipboard operations fail once you try to use them. * xclip is now "suggested" on Debian/Ubuntu. Unfortunately we cannot pull it in only in the presence of X11.
2025-03-01CI: the IRC posting is now in a separate workflow and runs only after ↵Robin Haberkorn2-17/+33
successful ci.yml runs * people are not spammed with commits, that may cause problems when they try to pull them and rebuild
2025-03-01CI: fixed posting of latest commits into the IRC channelRobin Haberkorn1-10/+17
* This will post on __every__ push. In the future, we might want to post only after successful CI and consequently since the last commit, that had a successful CI run.
2025-03-01CI: post all new commits into the IRC channelRobin Haberkorn1-0/+10
2025-02-15fixup: set the GH_TOKEN environment variable to fix using the `gh` tool in ↵Robin Haberkorn1-0/+2
nightly builds
2025-02-15nightly builds: use Github API to download pkg2appimage toolRobin Haberkorn1-2/+2
* the filenames contain commit hashes now, so it's no longer trivial to do with wget * should fix nightly builds
2025-01-19Mac OS nightly builds are relocatable nowRobin Haberkorn1-1/+4
* This means you should be able to install them into non-root directories. E.g.: sudo installer -pkg sciteco-curses_nightly_macos_x86_64.pkg -target test-installation
2024-12-27fixup: fixed installation of dependencies for win64-gtkRobin Haberkorn1-4/+4
2024-12-27nightly builds now include 64-bit Windows builds (MINGW64)Robin Haberkorn1-28/+28
* 32-bit binaries have been dropped, even though we could build both. But there is virtually no demand for 64-bit binaries left. * I continue to build 32-bit versions during CI, so that at least something still builds and tests under 32-bit.
2024-12-05nightly builds: use Mac OS 13 instead of the deprecated version 12Robin Haberkorn1-1/+1
* 13 is now the oldest supported version
2024-11-05fully support relocatable binaries, improving AppImagesRobin Haberkorn1-7/+12
* You can now specify `--with-scitecodatadir` as a relative path, that will be interpreted relative to the binary's location. * Win32 binaries already were relocatable, but this was a Windows-specific hack. Win32 binaries are now built with `--with-scitecodatadir=.` since everything is in a single directory. * Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`. This is not crucial for ordinary installations, but is meant for AppImage creation. * Since AppImages are now built from relocatable packages, we no longer need the unionfs-workaround from pkg2appimage. This should fix the strange root contents when autocompleting in AppImage builds. * This might also fix the appimage.github.io CI issues. I assume that because I could reproduce the issue on FreeBSD's Linuxulator in dependence of pkg2appimage's "union"-setting. See https://github.com/AppImage/appimage.github.io/pull/3402 * Determining the binary location actually turned out be hard and very platform-dependant. There are now implementations for Windows (which could also read argv[0]), Linux and generic UNIX (which works on FreeBSD, but I am not sure about the others). I believe this could also be useful on Mac OS to create app bundles, but this needs to be tested - currently the Mac OS binaries are installed into fixed locations and don't use relocation.
2024-10-30CI: disabled Valgrind altogetherRobin Haberkorn1-2/+2
* Apparently it's not possible to run it as part of CI.
2024-10-30CI: Valgrind does not work in the Ubuntu runners, so let's try it under Mac OSRobin Haberkorn1-4/+4
2024-10-30testsuite: added --valgrind option for running SciTECO under Valgrind (memcheck)Robin Haberkorn1-2/+2
* Any memory error will let the test case fail with code 66. * You can also call make check TESTSUITEFLAGS="--valgrind" * There is no program test for Valgrind in configure.ac for the time being. `valgrind` must be in $PATH. * All CI testsuite runs under Ubuntu are now with Valgrind.
2024-10-28Mac OS nightly builds: automatically extract package versionRobin Haberkorn1-1/+2
2024-10-25hopefully fixed win32-gtk nightly builds: explicitly draw in librsvg and ↵Robin Haberkorn1-4/+4
pixbuf loader file name changed
2024-10-16set target release to v2.2.0Robin Haberkorn1-1/+1
* The Mac OS package for v2.1.0 actually still encodes "2.0.0". But I am going to ignore this. It's not worth fixing, considering the experimental nature of the Mac OS builds.
2024-09-21disable shared libraries by defaultRobin Haberkorn2-14/+5
* This is necessary to fix the Unicode test suite on Win32, so I was always passing in --disable-shared manually. It's easy to forget though when building from scratch. * We don't currently install any (shared) library, so this is safe on all platforms. In fact on all other platforms, libtool detects that and doesn't generate wrapper binaries in any way. Only on win32 it's apparently buggy.
2024-09-17updated cheat sheetRobin Haberkorn1-0/+1
* character-based model, avoid mentioning "ASCII code" * added "0EE" example * should be built with pdfmom, so it's built with gropdf
2024-09-17Github pages are auto-generated from the Markdown files and HTML manuals nowRobin Haberkorn1-1/+24
* This pushes to the gh-pages branch since we don't yet want to introduce a new workflow (that would have to rebuild SciTECO). * Built as part of the nightly MacOS builds. The Ubuntu builds directly build Debian packages which do not contain the HTML manuals. * I don't want to check in images into the master branch. The gh-pages branch is cleaned with every build. Therefore I still cross-link to Sourceforge for any additional images and documents. * We could automatically build the cheat-sheet.pdf (TODO?). For the time being, we are still linking to Sourceforge.
2024-09-10fixed win32 CI and nightly builds (refs #5)Robin Haberkorn2-8/+17
* The libtool wrapper binaries do not pass down UTF-8 strings correctly, so the Unicode tests failed under some circumstances. * As we aren't actually linking against any locally-built shared libraries, we are passing --disable-shared to libtool which inhibts wrapper generation on win32 and fixes the test suite. * Also use up to date autotools. This didn't fix anything, though. * test suite: try writing an Unicode filename as well * There have been problems doing that on Win32 where UTF-8 was not correctly passed down from the command line and some Windows API calls were only working with ANSI filenames etc.
2024-09-10fixed Mac OS nightly builds by installing an up-to-date GroffRobin Haberkorn1-1/+2
The Mac OS 12 Groff apparently does not accept `-K` for preconv.
2024-08-24win32 CI: also set PDCURSES_CFLAGSRobin Haberkorn1-1/+4
Should fix `make distcheck`.
2024-08-23hopefully fixed the Windows CI testsRobin Haberkorn1-1/+2
* `make distcheck` will try to build against libncurses, which is not installed. Therefore, I set DISTCHECK_CONFIGURE_FLAGS in order to force it to PDCurses.
2024-08-23fully support out of tree buildsRobin Haberkorn2-13/+5
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla manually to the build directory. * It turns out, that Scintilla/Lexilla was supporting this since 2016. Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O). * For Scinterm I opened a pull request in order to add srcdir/basedir variables: https://github.com/orbitalquark/scinterm/pull/21 * `make distcheck` is therefore now also fixed. * The FreeBSD package is now allowed to build out of source. I haven't tested it yet. * See also https://github.com/ScintillaOrg/lexilla/issues/266
2024-05-23nightly builds: avoid uploading pkg2appimage.AppImageRobin Haberkorn1-3/+3
2024-05-22build and upload AppImages as part of nightly buildsRobin Haberkorn1-2/+16
2024-05-22ci.yml: hopefully fixed Mac OS CI builds - it appears we need sudo nowRobin Haberkorn1-1/+1
2024-05-22updated CI workflows: bumped some versionsRobin Haberkorn2-12/+12
* MacOS packages are now built on macos-12 since macos-11 has been deprecated.
2023-04-05fixed nightly Debian/Ubuntu buildsRobin Haberkorn1-1/+1
* Disabled pyTooling/Actions/releaser composite on Ubuntu and use a container instead. The composite step is obviously broken on Ubuntu 20.04.
2023-04-05Nightly Builds: hopefully fixed the Ubuntu buildsRobin Haberkorn1-4/+4
* pyTooling/Actions/releaser/composite updated to v0.4.6
2022-12-03fixup: bundle Gtk+ Win32 pixbuf loader DLLs into the package rootRobin Haberkorn1-6/+4
* mingw-bundledlls apparently does not output MinGW-friendly filenames, so we cannot use it to bundle files into a directory differing from the executable's directory.
2022-12-03nightly builds Win32 GtkRobin Haberkorn1-2/+2
* make sure that all DLLs are packaged into the root directory even those for the pixbuf loaders
2022-12-03simplified win32 packaging using mingw-bundedllsRobin Haberkorn1-12/+12
* mingw-bundledlls finds and copies transitive DLL dependencies. * Like all external one-file sources, mingw-bundledlls has been copied into contrib/ instead of adding a submodule. It's taken from here: https://github.com/mpreisler/mingw-bundledlls * Packaging is more robust now if dependant DLLs are upgraded or if we decide to link in more statically. With the old scheme, we might also miss some DLL and break builds without even noticing it.
2022-12-01nightly builds: create Mac OS *.pkg packagesRobin Haberkorn1-2/+7
This is slightly less idiosyncratic than shipping a tarball of the installation root. The pkg has been reported to be installable even via the graphic installer when providing a password. Or it can be installed via terminal with `sudo installer`. So it no longer requires any manual dequarantining.
2022-11-27Nightly Builds are uploaded as a Github release now instead of artefactsRobin Haberkorn1-64/+67
* replace actions/upload-artifact with pyTooling/Actions/releaser * The release URL will never change: https://github.com/rhaberkorn/sciteco/releases/tag/nightly * On the downside there is now a "nightly" tag in the repo that will be updated to HEAD whenever a nightly build runs - but other than that it does no harm. * Compared with artifacts, the new method has several advantages: * No more nightly.link Github App required * We can add arbitrary files into releases and no longer have to ZIP everything. So you can now download the Debian packages separately, the Mac OS "package" is a tar.gz (instead of zipped tar). For the Windows packages not much changes, though. * Files get updated in the "Nightly Builds" release even when individual jobs in the nightly.yml workflow fail. With artefacts, the entire workflow must be successful. * Releases are not deleted after 90 days as opposed to artefacts. So when my workflow breaks next time, there will still be files to download for a long time. * As a downside, the file names in the release have to be uniform and must not contain versions, commit hashes and dates so that uploads replace old files instead of adding new ones. Some manual cleanup could still be necessary after large packaging changes. This could be worked around, by uploading everything first as artefacts and updating the release in a separate job, but is not worth the trouble IMHO. * Another disadvantage is that there will be no old nightly builds to download (although these were not easily downloadable for end users before).
2022-11-20fixed nightly builds on Win32/Gtk: the libffi DLL name has changedRobin Haberkorn1-1/+1
* should fix Win32/Gtk packaging
2022-11-20fixed nightly builds on Win32: the PCRE DLL name has changedRobin Haberkorn1-2/+2
* Gtk packaging is quite possibly still broken
2022-11-20Github workflows: no longer try to build on deprecated runners like ↵Robin Haberkorn2-3/+3
ubuntu-18.04 and macos-10.15 As much as I like to support older systems, this will otherwise suddenly and unexpectedly break CI and nightly builds in the near future...
2022-06-21fixed win32-curses CI builds: build-wingui/contrib and build-wincon/contrib ↵Robin Haberkorn1-1/+1
were missing
2022-06-21Nightly builds: the PDCurses package will now contain both WinCON ↵Robin Haberkorn1-7/+20
(sciteco.exe) and WinGUI (gsciteco.exe) binaries * newer versions of PDCurses on MinGW contain both WinCON and WinGUI (static) libraries
2022-01-15fixed CI builds on WindowsRobin Haberkorn2-3/+3
* Autotools are apparently no longer preinstalled or part of base-devel.
2021-10-24added Mac OS nightly builds (#8)Robin Haberkorn1-7/+73
* 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
2021-10-24added ./configure --enable-debug and make sure that NDEBUG is defined properlyRobin Haberkorn1-3/+4
* This simplifies writing CFLAGS="-g -O0" CXXFLAGS="-g -O0". * We build "release" binaries by default. NDEBUG will now be defined unless you specify --enable-debug. This enables some optimizations that have long been implemented but were never actually active: * SciTECO shuts down faster since it will not explicitly free memory. On the downside, this would complicate memory debugging with Valgrind/memcheck. * dlmalloc is built with -DINSECURE=1 which is supposedly a bit faster. Some compilers also complained about an unportable preprocessor usage which should now be gone. * All CI builds are now with --enable-debug. This will slow them down but ensure that more code is executed and thus tested.
2021-10-24statically link Win32 Curses nightly builds and enable test suitesRobin Haberkorn1-17/+20
* There is little sense in linking the PDCurses builds statically as we have to ship most DLLs anyway. So we now link even the sciteco binary itself dynamically. This could save a few megabytes in the resulting Zip. * SciTECO is now fast enough to be able to run the test suites even on Win32.
2021-10-12CI on MacOS should only use ClangRobin Haberkorn1-0/+4
* Lexilla apparently does not build with GCC, although that seems to be a matter of build flags.
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-10 22:45:22 +0000