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? 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.
> >
>
> 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).
Regards,
Simon
