| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
* 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
|
|
(sciteco.exe) and WinGUI (gsciteco.exe) binaries
* newer versions of PDCurses on MinGW contain both WinCON and WinGUI (static) libraries
|
|
* Autotools are apparently no longer preinstalled or part of base-devel.
|
|
* 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
|
|
* 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.
|
|
* 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.
|
|
* Lexilla apparently does not build with GCC, although that seems
to be a matter of build flags.
|
|
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches).
All of the patches are now either irrelevant or have been merged upstream.
* Since Scintilla 5 requires C++17, this increases the minimum GCC version at least
to 5.0. We may actually require even newer versions.
* I could not upgrade the scintilla-mirror (which was imported from Mercurial),
so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0,
master was deleted and I reimported the entire Scintilla repo using
git-remote-hg.
This means that scintilla-mirror now contains two entirely separate trees.
But it is still possible to clone old SciTECO repos.
* The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed.
Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream
releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced),
we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3).
This branch is never rebased or deleted. Therefore, we are guaranteed to be able to
clone arbitrary SciTECO repo commits - not only releases.
Releases no longer have to be tagged in scintilla-mirror.
On the downside, fixup commits may accumulate in these new branches.
They can only be squashed once a new branch for a new Scintilla release is created
(e.g. by cherry-picking followed by rebase).
* Scinterm does no longer have to reside in the Scintilla subdirectory,
so we added it as a regular submodule.
There are no more recursive submodules.
The Scinterm build system has not been improved at all, but we use
a trick based on VPATH to build Scinterm in scintilla/bin/.
* Scinterm is now in Git and we reference the upstream repo for the
time being.
We might mirror it and apply the same branching workflow as with Scintilla
if necessary.
The scinterm-mirror repository still exists but has not been touched.
We will also have to rewrite its master branch as it was a non-reproducible
Mercurial import.
* Scinterm now also comes with patches for Scintilla which we simply applied
on our sciteco-rel-5-1-3 branch.
* Scintilla 5 outsourced its lexers into the Lexilla project.
We added it as yet another submodule.
* All submodules have been moved into contrib/.
* The Scintilla API for setting lexers has consequently changed.
We now have to call SCI_SETILEXER(0, CreateLexer(name)).
As I did not want to introduce a separate command for setting lexers,
<ES> has been extended to allow setting lexers by name with the SCI_SETILEXER
message which effectively replaces SCI_SETLEXERLANGUAGE.
* The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used
in the SciTECO standard library anyway - and have consequently been removed
from symbols-scilexer.c.
The style macros from SciLexer.h (SCE_...) are theoretically still useful - even
though they are not used by our current color schemes - and have therefore been
retained. They can be specified as wParam in <ES>.
* <ES> no longer allows symbolic constants for lParam.
This never made any sense since all supported symbols were always wParam.
* Scinterm supports new native cursor modes.
They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER
caret style is configured by default.
It makes no sense to enable native cursor modes now since the
command line should have a native cursor but is not yet a Scintilla view.
* The Scintilla upgrade performed much worse than before,
so some optimizations will be necessary.
|
|
* The testsuite now works on my Windows 2008 Server installation,
so hopefully it will also work on the build servers.
|
|
* We have to list all Win32 DLLs in LIBGLIB_LIBS since we
currently link it in statically.
|
|
* We don't need the PNG icons on Windows as the compiled-in ICO should suffice
* Ship the dependencies of the SVG pixbuf loader.
* The PNG pixbuf loader is still distributed, as we at least need it
for loading the icon theme.
* Install a loaders.cache - without it, the pixbuf loaders won't be found.
This file can be generated by gdk-pixbuf-query-loaders but apparently has
to be modified by hand.
* Regenerate the icon cache using gtk-update-icon-cache.
* Icon themes are found now.
Unfortunately, we have to distribute the entire Adwaita icon theme
as distributing only the scalable (SVG) icons does not work for some
strange reason (FIXME).
|
|
* follow the current terminology:
* PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well.
The Win32 GUI port is now called PDCurses/WinGUI.
* PDCurses/Win32 is now called PDCurses/WinCon.
* Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only
to detect PDCursesMod API extensions.
GUIs (detached from system console) might be available both in classic PDCurses as well
as in PDCursesMod.
Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version().
We therefore introduced a --with-interface=pdcurses-gui that must be given whenever
compiling for any kind of GUI port (including SDL on "classic" PDCurses).
* The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions.
* __PDCURSES__ is used to detect PDCurses whenever API extensions are not required.
* Assume that A_UNDERLINE now works even on WinCon.
|
|
* turns out that we need icon themes and pixbuf loaders as well
* GTK assumes an UNIX like hierarchy, so we package sciteco.exe and
all DLLs into a bin/ subdir.
* The SciTECO icons probably shouldn't be in bin/.
If we installed them into the hicolor icon theme, GTK might
pick them up automatically. This would work under Windows and UNIX.
* The GTK builds are still broken.
I do really need a real system (MSYS installation) to play around.
|
|
teco-gtk-label.gob to plain C
* Using modern GObject idioms and macros greatly reduces the necessary boilerplate code.
* The plain C versions of our GObject classes are now "final" (cannot be derived)
This means we can hide the instance structures from the headers and avoid using
explicit private fields.
* Avoids some deprecation warnings when building the Gtk UI.
* GOB2 is apparently no longer maintained, so this seems like a good idea in the long run.
* The most important reason however is that there is no precompiled GOB2 for Windows
which prevents compilation on native Windows hosts, eg. during nightly builds.
This is even more important as Gtk+3 is distributed on Windows practically
exclusively via MSYS.
(ArchLinux contains MinGW gtk3 packages as well, so cross-compiling from ArchLinux
would have been an alternative.)
|
|
* These builds generally work, but function keys appear to be broken.
This does not happen when building with the latest PDCursesMod on my machine.
* <EC> appears to be broken.
* We try to link everything statically since MSYS provides actually working
static libglib builds.
Unfortunately, their gspawn helper executables are still linked normally,
so we have to pull in most DLLs anyway.
Considering that GTK cannot be linked statically, we should perhaps
simply link the Curses builds dynamically as well.
|
|
* The testsuite still fails and I cannot fix it without a Windows system or VM at hand.
* Problems are probably related to <EC> (spawning).
* Simply disabling the test suite would not make much sense as
we already try building using nightly.yml.
|
|
Github logs when it fails
|
|
after all
* the tools installed by default seem to lack aclocal...
|
|
meaningful artifact names
* Try to use as much of the "native" (Xcode?) tools on macOS as possible.
We can still fall back to Homebrew if we have to.
|
|
|
|
|
|
builds) and include Gtk+ versions
* The CI tests are unchanged. The workflow file has been renamed to ci.yml, though.
* Nightly builds are described by nightly.yml and are built at 4:13.
* Nightly Ubuntu package builds now include the Gtk+ 3 packages.
|
|
nightly builds in README
|
|
assignment to fix "Xvfb failed to start" (hopefully)
|
|
* We need some kind of XServer to run sciteco during the build process
and for the test suite, so we have to run everything via xvfb-run.
|
|
This will hopefully fix downloading libgtk-3-dev.
|
|
and compiler
|
|
Clang and package for both versions of Ubuntu
* Testing is done only in the "build-and-test" job.
* Packages are built by the debian-packages job since
there is no need building them with Clang.
|
|
|
|
|
|
|
|
Will be extended for Continuous Deployment and using all sorts of build environments.
|
