Am Do., 30. Sept. 2021 um 17:29 Uhr schrieb Jack Rosenthal <jrosenth@google.com>:

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