Re: [docs] [bitbake-devel] [PATCH 3/4] knotty: convert warnings to errors when -W is passed

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2026-10-21 at 16:42 +0200, Antonin Godard wrote:
> On Sat Oct 17, 2026 at 5:02 PM CEST, Richard Purdie wrote:
> > On Fri, 2026-10-16 at 15:11 +0200, Antonin Godard via lists.openembedded.org wrote:
> > > Hi,
> > > 
> > > On Fri Oct 16, 2026 at 9:59 AM CEST, Michal Sieron via lists.openembedded.org wrote:
> > > > Hi,
> > > > 
> > > > two cents from my side. I think that warnings as errors would ideally work like normal -Werror in compilers.
> > > > 
> > > > 1. Regarding name: -W doesn't indicate anything about errors. Only something
> > > >    with warnings. I am not sure if having this short option is worth it.
> > > 
> > > I agree.
> > > 
> > > > 2. This might be controversial, but ability to do -Wno-error, would be great.
> > > >    Problem is we don't have categorized/named warnings/errors. But I think
> > > >    that it could support a syntax where we use file name (or partial match on
> > > >    its path) and disable warnings-as-errors for that source file. Or this
> > > >    might be even easier to implement: regex for warning message. It it
> > > >    matches, it won't be treated as an error.
> > > 
> > > That sounds like an interesting idea - but maybe as a follow-up of this though?
> > > 
> > > > 3. Exit code only change won't force developers to immediately fix their code
> > > >    as it's really easy to ignore in interactive terminals. Sure, later CI
> > > >    would catch it, but I would prefer early fail if possible.
> > > 
> > > That's true - however, I checked again, and error messages originating from
> > > bb.error (or bberror) do NOT stop the execution of bitbake. This is the role of
> > > bb.fatal (or bbfatal). bb.error only affects the return code of bitbake, but
> > > goes as far as possible - for example I was able to build an image recipe even
> > > though one of its recipes emitted a bb.error.
> > > 
> > > So if we want warnings to act like errors, I think this is already what this
> > > series does. If we want warnings/errors to act like bb.fatal, that's another
> > > question.
> > 
> > I should also mention that ERROR_QA and WARN_QA allow many warnings to
> > actually become errors. That is the mechanism we should really be
> > pointing people at if they want errors IMO...
> 
> Sure, but this couldn't possibly cover all warnings?

No, it doesn't. People are often solving subtly different problems
though and those give a different set of controls.

> Maybe I can reword the intent of this series: give users an easy way of knowing
> when one or more warnings were emitted so that they look at them instead of
> ignoring them.
> 
> Whether we should stop bitbake immediately on a warning or not seems to be
> another question as per my previous email.

Stopping immediately probably irritates users. We get into subtle
problems though as if you continue and let the task get marked as
success, the next build won't show the error. Even a clean build with
existing sstate can not show warnings which were shown the first time.

Including warnings in the sstate objects works to a point, for the
warnings on the sstate task specifically, but what if those warnings
come from an intermediate task like do_install? Those wouldn't get
captured anywhere even if we have sstate warnings :(.

> From your answers, I'm not really sure of whether you approve or deny of this
> idea though. Should I send a v2 with a long option only (--fail-on-warnings),
> and keep the rest as-is?

I'm torn.

If we do something, I do want the design to be consistent and for the
behaviour to be really clear. I'm therefore trying to show the
different corner cases I can think of. I don't have a good idea of what
the end result should look like, I do know it needs thought which I
don't really have the time to d justice myself :(.

If we don't do that, there will just be a stream of patches, each
subtly changing the behaviour to match what a given user wants at the
expense of others.

Cheers,

Richard