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

["Antonin Godard" <antonin.godard@bootlin.com>]

On Thu Oct 15, 2026 at 3:04 PM CEST, Richard Purdie wrote:
> On Thu, 2026-10-15 at 14:23 +0200, Antonin Godard wrote:
>> On Thu Oct 15, 2026 at 1:49 PM CEST, Richard Purdie wrote:
>> > On Thu, 2026-10-15 at 12:25 +0200, Antonin Godard wrote:
>> > > On Thu Oct 15, 2026 at 10:58 AM CEST, Richard Purdie via lists.yoctoproject.org wrote:
>> > > > On Tue, 2026-10-13 at 14:13 +0200, Antonin Godard via lists.openembedded.org wrote:
>> > > > > When -W is passed, modify the handlers to show warnings in red and set
>> > > > > the return value to 1. Add a summary line informing the user that the -W
>> > > > > option was used as it might not be obvious when looking at the bottom
>> > > > > the end of the console log.
>> > > > 
>> > > > The trouble is this doesn't make warnings behave exactly as errors and
>> > > > I think that is going to confuse people :/.
>> > > > 
>> > > > Specifically, if an error is encountered in a task, it will error and
>> > > > fail. The warning will show an error but continue anyway. I also
>> > > > suspect the warnings will still show as warnings in the log files and
>> > > > only appear as errors on the console.
>> > > 
>> > > Good point. So there's two directions this could take (if we want that feature):
>> > > 
>> > > - Make this option change the behavior of warnings, and make them _act_ (not
>> > >   just look) like errors, so a given task would stop in case of warning.
>> > > 
>> > > - Rename the option and make it clearer: warnings are still warnings but the
>> > >   return code will be 1 if there are any.
>> > > 
>> > >   Maybe "-W,--fail-on-warnings: Make bitbake return 1 if any warning is
>> > >   emitted"?
>> > > 
>> > > I feel like the second option might be best as the first one is changing the
>> > > behavior of tasks and I also think this might not be desirable.
>> > > 
>> > > With the second option it allows having a positive exit code on warnings while
>> > > still being able to have a look at all of them (not only the single one that
>> > > stopped the build as would happen with the first option), just as you would with
>> > > a normal bitbake execution.
>> > 
>> > I think we need to see if there are others wanting this feature or not.
>> > I think with new option additions like this, we need to see a clear
>> > demand from the userbase for it. That feedback may also make it clearer
>> > which behaviour people would want.
>> 
>> Ross (copied here) was talking about it on IRC[1]. Hard to say which way or the
>> other was desired from this conversation though. It did give me the idea to
>> contribute this feature as I also need it sometimes.
>> 
>> I personally have seen multiple projects where builds started in CI environments
>> needed to stop when warnings are emitted. I'm happy to keep my scripts as they
>> are but I thought this series would make things a bit easier for users.
>
> Do you really want to "stop" on warnings though? Usually you want a
> list of *all* the warnings, not just the first one. You probably do
> want to continue through all the rest of the tasks too.

No, I don't want to stop on the first warning. I wasn't clear, sorry.

> That makes it sound like you want to just change the exit code, which
> is a bit of a different discussion...

Yes, exactly, the goal would be to return 1 if at least 1 warning is emitted,
which I think is a common use-case.

Antonin