| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
from MSYS
Ther rest of mingw32 still appears to exist, though.
|
|
* The default womanpage font is the abstract "Serif" now, so that should be
more portable. "Times" wasn't found on Windows.
* Win32 distributions include a custom .teco_css now, which
removes the small-caps font attribute from the type label.
The default Gtk theme on Windows references the "Segoe UI" font
and it doesn't have a small-caps variant.
In fact no default Windows font appears to have one.
* We could add a custom .teco_ini to win32 distributions as well,
but there is currently no need for it.
* Do not distribute the /win32 files. They are used only for building
Win32/64 packages. There is no point in distributing them in the tarball if
the /debian and /freebsd directories aren't distributed as well.
|
|
|
|
* We can therefore no longer provide 20.04 nightly builds.
Perhaps I will manually build binary releases for the v2.4.0 release for the last time.
The PPA will still provide 20.04 of course.
* The AppImages are consequently also built based on the Ubuntu 22.04 packages,
which are now the oldest supported ones.
|
|
--enable-html-docs
* `--enable-html-manual` renamed to `--enable-html-docs`.
* It's also uploaded to the website and linked to in README.
|
|
groff is now required in its entirety
|
|
* 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.
|
|
|
|
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.
|
|
As I cannot run the test suite with Valgrind in Github runners,
this should still catch some memory bugs during test suite runs.
|
|
* 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.
|
|
successful ci.yml runs
* people are not spammed with commits, that may cause problems when they try to pull them and rebuild
|
|
* 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.
|
|
|
|
nightly builds
|
|
* the filenames contain commit hashes now, so it's no longer trivial to do with wget
* should fix nightly builds
|
|
* 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
|
|
|
|
* 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.
|
|
* 13 is now the oldest supported version
|
|
* 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.
|
|
* Apparently it's not possible to run it as part of CI.
|
|
|
|
* 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.
|
|
|
|
pixbuf loader file name changed
|
|
* 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.
|
|
* 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.
|
|
* character-based model, avoid mentioning "ASCII code"
* added "0EE" example
* should be built with pdfmom, so it's built with gropdf
|
|
* 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.
|
|
* 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.
|
|
The Mac OS 12 Groff apparently does not accept `-K` for preconv.
|
|
Should fix `make distcheck`.
|
|
* `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.
|
|
* 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
|
|
|
|
|
|
|
|
* MacOS packages are now built on macos-12 since macos-11 has been deprecated.
|
|
* Disabled pyTooling/Actions/releaser composite on Ubuntu and use a container instead.
The composite step is obviously broken on Ubuntu 20.04.
|
|
* pyTooling/Actions/releaser/composite updated to v0.4.6
|
|
* 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.
|
|
* make sure that all DLLs are packaged into the root directory even
those for the pixbuf loaders
|
|
* 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.
|
|
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.
|
|
* 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).
|
|
* should fix Win32/Gtk packaging
|
|
* Gtk packaging is quite possibly still broken
|
|
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...
|
|
were missing
|
