On Mon, May 04, 2026 at 05:14:13AM -0600, Simon Glass wrote: > Hi Quentin, > > On Wed, 29 Apr 2026 at 10:32, Quentin Schulz <[email protected]> wrote: > > > > On 4/29/26 4:25 PM, Tom Rini wrote: > > > On Wed, Apr 29, 2026 at 08:18:14AM -0600, Simon Glass wrote: > > >> Hi Tom, > > >> > > >> On Mon, 27 Apr 2026 at 08:46, Tom Rini <[email protected]> wrote: > > >>> > > >>> On Mon, Apr 27, 2026 at 11:54:09PM +1200, Simon Glass wrote: > > >>>> Hi Quentin, > > >>>> > > >>>> On Thu, 23 Apr 2026 at 22:24, Quentin Schulz > > >>>> <[email protected]> wrote: > > >>>>> > > >>>>> Hi Simon, > > >>>>> > > >>>>> On 4/22/26 11:57 PM, Simon Glass wrote: > > >>>>>> Hi Quentin, > > >>>>>> > > >>>>>> On Thu, 23 Apr 2026 at 01:26, Quentin Schulz > > >>>>>> <[email protected]> wrote: > > >>>>>>> > > >>>>>>> Hi all, > > >>>>>>> > > >>>>>>> I'm looking into force-enabling CONFIG_WERROR for all Rockchip SoCs. > > >>>>>>> First, let me know if this is a bad idea :) > > >>>>>> > > >>>>>> I don't like it, as it makes development slower. I like to see all > > >>>>>> the > > >>>>>> warnings created by a change and tend to fix them iteratively. We > > >>>>>> already have a warning check in CI. A better approach is to > > >>>>>> > > >>>>>> Can you use: KCFLAGS=-Werror > > >>>>>> > > >>>>>> either in your environment or on the 'make' cmdline? > > >>>>>> > > >>>>> > > >>>>> Well, if it's during development, you can always disable WERROR? The > > >>>>> fact that I've never actually enabled -Werror locally in about a > > >>>>> decade > > >>>>> in U-Boot probably isn't a good sign. One of the things that make me > > >>>>> wary though is compiler updates with new warnings. I've tested with > > >>>>> clang 22, don't know when clang 23 is planned to be released. GCC 16 > > >>>>> is > > >>>>> about to be released as well. > > >>>>> > > >>>>> By having the check in CI, we have a longer-than-necessary feedback > > >>>>> loop > > >>>>> for contributors. Has this been an issue in the past? /me shrugs > > >>>> > > >>>> This is strange though, because people should see the warnings during > > >>>> development. I wonder if it is scrolling off the screen. > > >>>> > > >>>> One my bugbears is non-actionable output. When the build succeeds > > >>>> (with no warnings) I see no output, using 'buildman -I --board xxx -w > > >>>> -o /tmp/b/xxx' or in fact these days 'um build xxx'. This uses 'make > > >>>> -s' under the hood, so that it doesn't print a huge list of filenames, > > >>>> etc. I also sometimes do a 'fresh' build with 'um build -F xxx' to > > >>>> check everything is clean ('buildman -m' does something similar). > > >>>> > > >>>> Note that buildman returns exit code 101 if there are any warnings, so > > >>>> the build basically fails. > > >>>> > > >>>>> > > >>>>> No defconfig seems to be setting this option, not sure exactly why > > >>>>> that is. > > >>>> > > >>>> To me this is a difference between 'functionality' options and > > >>>> development options. Putting development options in Kconfig makes it > > >>>> harder to turn them on and off, since you must either edit the > > >>>> defconfig or edit the .config file. It is easier to just pass an > > >>>> environment variable. > > >>> > > >>> The point of a configuration is that it configures the build. Stuff in > > >>> environment (directly or make FOO=bar) is a workaround and anti-pattern. > > >>> Having to run one of the config front-end to change the config is a > > >>> feature, and good thing. > > >> > > >> To give an example, we have boards which enable LTO, but it is > > >> sometimes useful to disable it during development - it used to be a > > >> huge time sync but something seems to have changed recently, as I > > >> don't see much of a performance gap now. We don't want people > > >> disabling LTO in the defconfig, though. The same applies for things > > >> like V=1 > > >> > > >> So I think there are build features which are of no use to end-users, > > >> but are helpful for development. That is the distinction we have had > > >> for a while and it would be a shame to lose it. > > > > > > Yes, the LTO thing is a good example of something we shouldn't have done > > > really. Outside of sandbox you cannot just disable it. > > Are you sure about that?
Yes. Outside of sandbox LTO is enabled because the platform binaries
will exceed their non-optional size constraints.
> I seldom build with LTO, except for CI. For
> an incremental build the non-LTO is often twice as fast. Most of the
> time when developing new features I am just trying to make things
> work, so it is big time-saver in the IDE. To some extent this is
> changing, though (LSPs and AI tools). The main impact for me is with
> sandbox incremental builds.
We could maybe just drop LTO from sandbox, now that it's enabled more
widely on hardware.
> > >
> >
> > FYI, the Linux kernel defaults to CONFIG_WERROR=y. See commit
> > 3fe617ccafd6 ("Enable '-Werror' by default for all kernel builds")
> > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3fe617ccafd6f5bb33c2391d6f4eeb41c1fd0151).
>
> Do we suffer from this same problem?
>
> >
> > I wouldn't necessarily recommend to switch it on right now, but I think
> > it could be a good idea in the mid-term. We're also very far behind in
> > terms of warn flags compared to the kernel. Syncing will take some time
> > though. For now I'm looking into enabling -Werror for host tools and
> > this resulted in (so far) 21 patches.
>
> I must be misunderstanding what you are referring to here. I don't see
> any warnings when building tools-only - certainly I would not put up
> with that. Do you mean that you are enabling additional warnings?
>
> We already have CI checking (which fails on the first warning) and we
> already show the warnings for normal builds. Importantly, without
> -Werror, we show *all* the warnings rather than just stopping at the
> first one depending on -j, etc.
>
> So forcing this option seems to be a tax on people who fix warnings,
> imposed by those who don't. It really should be the other way around
> :-)
>
> BTW we do have KCFLAGS which can be used to set Werror (and also
> perhaps other things).
I'll note that I just had to request changes on another patch because
they didn't realize warnings had to be fixed. It's quite likely that
making CONFIG_WERROR=y will save more people more time (maybe document
make -k? I don't know what people don't know about these days, but I do
"make -kj" a lot when doing the randconfig stuff for example) than what
we do today.
--
Tom
signature.asc
Description: PGP signature
