Speaking as the person who wrote the first few config tools in python, and was happy to see the python dependency gone, I think bringing python back in would be a mistake.
Every single python test framework I've worked with works until there is a problem, and I then find myself having to walk back a python call trace, because what inevitably breaks is the test framework tooling. It's why so many projects are removing python test frameworks. If you want a good test framework, get the linuxboot fork of facebook's contest github.com/linuxboot/contest, written in Go, in use at scale near you. It's easy to let the joy of building a build system overwhelm the actual goals of a project. coreboot is not about being a build system. It's easy to fall into the trap of creating an ever more complex system that is more than is needed. On Thu, Sep 30, 2021 at 9:11 AM Patrick Georgi via coreboot <coreboot@coreboot.org> wrote: > > Am Do., 30. Sept. 2021 um 17:29 Uhr schrieb Jack Rosenthal > <jrose...@google.com>: >> >> With respect to Kconfig, we (at Google) encountered a lovely build flake >> after the Kconfig uprev last month in the coreboot tree that took a couple >> of weeks to sort out and resolve. Some sort of automated validation that the >> code is working could have possibly helped. Of course, the C implementation >> of Kconfig has no tests at all. Some tests is better than nothing. > > > Let me put the record straight: > > - The last kconfig "uprev" hasn't been a simple update the way > https://review.coreboot.org/c/coreboot/+/57880 is, but rebuilt the entire > build system integration to ease maintenance > - That issue sprang up because before the kconfig update, we were shipping > prebuilt parser files (C code) while now we made bison and flex hard > dependencies for our build > - Tests covering the C code wouldn't have helped, because the issue wasn't in > the C code > - The issue we were facing has been an external dependency (namely: the > Chromium OS development environment shipping a broken version of bison(1)) > - Fixing bison in CrOS wouldn't have helped any because we have to assume > that other users come with the same kind of broken bison tool > - The fix has been to ship pre-built files again to remove an external > dependency > > The alternative that we did actually consider was to add support for building > bison and flex to util/crossgcc/buildgcc. For three files that's sheer > madness, so we went back to precompiled files instead. > > In relation to your proposal to adopt kconfiglib: We can run into any kind of > external tool demonstrating weird behavior. That's true for bison (as seen > here) just as it can be true for arbitrary python versions (even when > specified to be "python 3.6+" or whatever): Linux distributions do strange > things to their packages, and we're not a Linux-only project, so even > official, unchanged, straight-from-the-server python might behave > unexpectedly on less well exercised platforms. > > The best way to reduce issues on that end is to avoid external dependencies - > like bison, like flex... like python. > I'd _love_ to avoid the dependency on the host compiler as well, but that's > one of those "sheer madness" moments when you support a multitude of > operating systems on as many architectures. > > Introducing kconfiglib (and through it, a deep reliance on python) just > doesn't seem to provide comparable benefits. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
