[xiphos-devel] windows build

[Greg Hellings]

On Wed, Apr 22, 2020 at 10:01 PM Karl Kleinpaste <karl at kleinpaste.org>
wrote:

> I went looking into the Windows build today.
>
> The situation is very ugly. Problem is that many needed, old packages are
> no longer supported, no longer available at all. And in #963, Dom tells us
> that functional gtk3 for Windows can't be expected any time soon, so we
> won't be able to use the modern versions of these old packages.
>

The deeper I go, the more I realize there is little, if any, support for
toolkits with HTML displays that run on Windows besides Qt and wxWidgets.
GTK has completely given up and doesn't want anything to do with it.
Although WebKit supports Windows, the GTK port of it does not.


> So I went looking for other solutions. Most straightforward in appearance
> was to go to an archive of Fedora 30 packages to find the last
> mingw-webkit*.rpm before they went obsolete in F31. I've now got a copy of
> every mingw RPM from F30 including updates, and I could install any of them
> I need, except for one little detail: Some of them depend on similarly old
> packages, but those other old packages are still supported, meaning that
> more recent versions exist and are necessarily installed for other reasons.
>
> Example: We need mingw64-webkitgtk. It depends on a particular release of
> ICU. But ICU is still supported, so there exists a modern
> mingw64-icu-whatever package. I can't install the old ICU RPM that's
> compatible with mingw64-webkitgtk RPM alongside the modern ICU.
>
> What I am currently contemplating, if I can keep my stomach from
> revolting, is gathering all the needed ancient mingw packages, and putting
> them together in a special drop-in environment by extracting the packages
> with rpm2cpio. Just create a monolithic blob for our own use. That is, the
> content will be present, but not known to the system as a whole in an
> RPMish way. Update the cmake system to use a peculiar PKG_CONFIG_PATH for
> Windows that includes this blob.
>
> Comedy is not pretty.
>
> I'm wide open to countersuggestions for how to resurrect the Windows build.
>

This is exactly the situation that Containers and VMs are perfectly suited
for. Using Docker or Podman (docker isn't compatible out of the box with
F31 because of cgroupsv2 issues - it seems fixed in F32 betas that I've run
but I wouldn't swear to it) you can spin up a Fedora 30 system on top of
any running machine you want, use dnf the way it was meant to be, and
proceed onward. Is there a reason to not pursue that? This is how I build
the mingw{32,64}-sword binary files that are available on Github, even
though the build systems are running Ubuntu (both Travis CI and Github
Actions have Ubuntu as the default VM runner and don't let you select
anything else).

If you don't like Podman/Docker then a simple Vagrant vm would also be
feasible. I've considered converting the build system over to either/both
of those. It will remain frozen in time at the end of the F30 life,
whichever you choose, and avoids you needing to do whacky things like
you're contemplating. It also can make it very easy for anyone who wants to
initialize the build from their system (docker build/podman build/vagrant
up) to get it done in a single invocation.

Using Docker is probably better for compile tasks, because it doesn't incur
a virtualization penalty and it's very lightweight in terms of
requirements. And, these days, it runs on Windows as well.

The problem is that GTK2 eventually just /won't work/ in some new version
of Windows at some time in the far future. And then we'll be stuck up a
creek without a paddle.

--Greg

> _______________________________________________
> xiphos-devel mailing list
> xiphos-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20200422/e615295f/attachment.html>