Hi Mauro, On 28/08/2023 19:46, Mauro Carvalho Chehab wrote: > 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. Of course, but if you want to get your code into the kernel it is good if you can reproduce whatever system the subsystem maintainers use to avoid wasting time. That's the reason for using the same toolchain. The other reason is that it allows us to switch to a new compiler quickly. Especially a new gcc major release will often introduce a bunch of new warnings, and it is nice not having to wait for distros to pick up a new version. For day to day development you use whatever compiler version you want, it is not intended that you use these cross compilers for your normal development process. It is purely to ensure you have the same environment as the CI environment. > >> 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. I only use released gcc versions, I never use pre-release versions. I leave that to those early testers. And this is not about breaking compilation: it is very, very rare that a source compiles for a newer version but not for an older version. It is primarily about compiler warnings as there is much more variation there between compiler versions. We want to keep the number of warnings at 0, both for -Werrors and for making it easy to detect new warnings. By and large, newer compilers will have more warnings than older compilers, so using the latest released compiler has been my preference over the years that I ran the daily build. Regards, Hans > > 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
