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