<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 22, 2020 at 10:01 PM Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<font face="FreeSerif">I went looking into the Windows build today.<br>
<br>
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.<br></font></div></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font face="FreeSerif">
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Comedy is not pretty.<br>
<br>
I'm wide open to countersuggestions for how to resurrect the
Windows build.<br></font></div></blockquote><div><br></div><div>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).<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>--Greg<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font face="FreeSerif">
</font>
</div>
_______________________________________________<br>
xiphos-devel mailing list<br>
<a href="mailto:xiphos-devel@crosswire.org" target="_blank">xiphos-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/xiphos-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/xiphos-devel</a><br>
</blockquote></div></div>