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.