| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* 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.
|
