Re: Fox toolkit future?

Enno Rehling <[email protected]> Sun, 25 Jun 2023 20:57:14 +0200
Newsgroups gmane.comp.lib.fox-toolkit.user
Message-ID <[email protected]>
On 25-Jun-23 18:25, Ulrich Teichert wrote:
> Hi Enno & all,
> 
>> Getting "it compiles on all supported platforms, not just on yours" is
>> extremely valuable feedback, a lot better than having none at all.
> 
> Yes, been there, done that (actually, I've done it twice already working for
> two different companies...). But by default GitHub will only get you feedback
> about Ubuntu on AMD64, Windows on AMD64 and MacOS (dunno if they made the step
> to AARCH64 already...). For any other platform you have to provide the runners
> 24/7. Now that I think of, this could be probably best done with latent runners
> on buildbot (think of starting a VM on demand on QEMU for all the supported
> platforms). But anyway, it would be a lot more effort than just writing a few
> lines of yaml. Just starting with the default set and adding the other
> platforms later will get you going, sure, but if just stops with the default
> set of platforms the gain will not be much, IMHO.

There are existing github actions that can be used to build on other 
platforms using QEMU. It's how I build Debian packages for ARM platforms 
(those pesky Raspberry Pi users). Took a while to figure out the first 
time, and isn't as quick as native builds, but definitely works.

>> And the ability to run unit tests during CI is usually the first step
>> towards someone making the effort to writing them. Regarding your
>> concern about visual testing: It's possible to write tests that render
>> to a virtual framebuffer (like xvfb) and do screenshot comparisons. A
>> lot of browser testing works like that.
> 
> Yes, I've written selenium tests in the past. While this may work for a time
> these tests are likely to break with the smallest possible changes and
> are high maintenance infrastructure. Personally, I would not like to
> maintain them. Would you? Perhaps it would be better to start writing
> self tests (not necessarily unit tests, depending on how strict you do
> the categorization...) inside the framework and see how far that could be
> driven to.

It depends on how much visual changes there are over time, but yes, this 
kind of testing is absolutely labor-intensive. I just wanted to point 
out that it's possible, if such a thing was desired.

Enno.