Em Mon, 28 Aug 2023 16:14:56 +0200 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > Hi Jacopo, > > On 28/08/2023 16:05, Jacopo Mondi wrote: > > Hi Hans > > > > On Mon, Aug 28, 2023 at 03:29:41PM +0200, Hans Verkuil wrote: > >> Hi all, > >> > >> We have been working on simplifying the media maintenance, and one part of that is > >> standardizing on build tools, in particular to make it easier for patch submitters > >> to run their patches through the same set of tests that the daily build does. > >> > >> This helps detect issues before you submit your patches. > >> > >> I have been working since July on transforming my hackish scripts to something > >> that is easier to use and of better quality. While there are still a few rough > >> edges, I consider it good enough to have others start to use it. > >> > >> To get the build scripts run: > >> > >> git clone git://linuxtv.org/hverkuil/build-scripts.git > >> > >> All the test builds will happen within this directory. It is completely separate > >> from where you do you normal development, instead you point it to where your > >> git repository is. > >> > >> See the README contained in the build-scripts git repo for all the details on > >> how to set it up. > >> > > > > I've been using your scripts since after ELC-E and I can tell they're > > useful! > > > >> Currently the scripts expect a debian 12-based distro (likely debian 11 will work > >> as well). I have no idea if it works well on Red Hat or Suse. If you use one of > >> those distros, and you get it to work, then a patch updating the README file with > >> the correct list of packages to install would be welcome. > >> > > > > Speaking about distros, I was wondering if you still consider a > > requirement to build all compiler or we should instead try to use the > > distro provided ones when possible to test the distro-shipped version > > ? > > I strongly believe we should build the cross compilers. The reason is that > otherwise you get a wide variety of compiler versions, each with typically > different compiler warnings. It's a pain for a developer to see different > warnings than the person that merges those patches. I disagree. We don't want to break build for any supported compiler version. With Werror enabled, this can be tough. So, having people using different versions is actually a good thing. > It's a a regular problem that the daily build sees different warnings than > you do locally with the distro's compiler. Sparse (or smatch) will produce different warnings anyway, even with the same version, depending on how many times you run it, and if you create a database or not. > > Doing it this way also makes it easier to upgrade to the latest compiler > version, certainly quicker than a distro would do. Usually, Fedora is very quick upgrading to the latest compiler. Yet, I don't think this should be the main goal. I bet people will be a lot pickier if we break compilation against a gcc version on Ubuntu, Suse, Fedora and variants than if you break compilation about an upcoming gcc version that are used by just a bunch of early testers. Btw, there are early testers for both gcc and clang that periodically test them during compilers -rc stages. They'll likely identify issues before us (as it already happened in the past). > > It's about reproducibility, really. > > Regards, > > Hans > > > > >> Please note that running the regression tests using virtme-ng is currently only > >> supported on Debian 12, not on e.g. Ubuntu. Someone is looking into that, and > >> hopefully we can support that in the future. Running regressions tests are > >> primarily useful when making changes to core frameworks and public APIs, and > >> it is possible to run them manually (see the README). > >> > >> Since running this locally can take a fair amount of time, we hope to have > >> build servers available in the future so this can be offloaded. > >> > >> To give an idea of the expected build times: > >> > >> On an AMD Ryzen 9 6900HX (8 cores) a standard build of the staging tree > >> (build.sh -test all) takes 39 minutes. > >> > >> On an AMD Ryzen Threadripper 3970X (32 cores) it takes a bit over 13 minutes. > >> > >> Regards, > >> > >> Hans > >> > >> _______________________________________________ > >> linuxtv-ci mailing list > >> linuxtv-ci@xxxxxxxxxxx > >> https://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-ci > > > _______________________________________________ > linuxtv-ci mailing list > linuxtv-ci@xxxxxxxxxxx > https://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-ci
