CONFIG_WERROR is useful for all build steps, not only compilation of C and
Rust sources linked into the kernel.

Also enable it for assembler and linker invocations, userprogs, as well as
C and Rust hostprogs.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (2):
      kbuild: move existing CONFIG_WERROR flags into dedicated Makefile
      kbuild: enable CONFIG_WERROR for more build steps

 Makefile                   |  4 +---
 scripts/Makefile.extrawarn |  2 --
 scripts/Makefile.werror    | 18 ++++++++++++++++++
 3 files changed, 19 insertions(+), 5 deletions(-)
---
base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
change-id: 20250801-kbuild-werror-081f72fee1de

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

On Tue, Aug 12, 2025 at 7:31 AM Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> CONFIG_WERROR is useful for all build steps, not only compilation of C and
> Rust sources linked into the kernel.
>
> Also enable it for assembler and linker invocations, userprogs, as well as
> C and Rust hostprogs.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

The Rust part is:

    https://lore.kernel.org/rust-for-linux/20240519211235.589325-1-ojeda@kernel.org/

However, Masahiro back then mentioned that we shouldn't make the C
host flags depend on `WERROR` since `HOSTCC` builds Kconfig and, for
consistency, not for Rust host progs either:

    https://lore.kernel.org/rust-for-linux/CAK7LNATPx2wTEM=KDmGtcH8vVTB4suOhh-CUQKP54F8wtPWDiw@mail.gmail.com/

Perhaps it could make sense to explicitly exclude certain bits, like
Kconfig, from `WERROR`, and apply it for everything else instead.

Cheers,
Miguel

Hi Miguel,

On Tue, Aug 12, 2025 at 11:21:24AM +0200, Miguel Ojeda wrote:
> On Tue, Aug 12, 2025 at 7:31 AM Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> >
> > CONFIG_WERROR is useful for all build steps, not only compilation of C and
> > Rust sources linked into the kernel.
> >
> > Also enable it for assembler and linker invocations, userprogs, as well as
> > C and Rust hostprogs.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 
> The Rust part is:
> 
>     https://lore.kernel.org/rust-for-linux/20240519211235.589325-1-ojeda@kernel.org/

Thanks for the pointer. We can keep the logic in Makefile.extrawarn.
But adding FLAGS-y machinery for all of the flags will be a bit noisy.
Having one ifdef CONFIG_WERROR around everything is much easier to read.

> However, Masahiro back then mentioned that we shouldn't make the C
> host flags depend on `WERROR` since `HOSTCC` builds Kconfig and, for
> consistency, not for Rust host progs either:
> 
>     https://lore.kernel.org/rust-for-linux/CAK7LNATPx2wTEM=KDmGtcH8vVTB4suOhh-CUQKP54F8wtPWDiw@mail.gmail.com/

That does make sense.

> Perhaps it could make sense to explicitly exclude certain bits, like
> Kconfig, from `WERROR`, and apply it for everything else instead.

The users will still pass -Werror explicitly, we can't filter that out.

Let's skip hostprogs for now. Another possibility would be to use -Werror
for hostprogs unconditionally. Various tools/ are doing that for example.


Thomas

On Tue, Aug 12, 2025 at 12:25 PM Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> The users will still pass -Werror explicitly, we can't filter that out.

You mean the user passing them when calling `make`, right? I guess we
could perhaps try to be smart there, but yeah, it gets annoying.

Another option could be to have a new `NOCONFIGCC` that gets used only
for Kconfig and that defaults to `HOSTCC`.

> Let's skip hostprogs for now.

Sounds good, thanks!

> Another possibility would be to use -Werror
> for hostprogs unconditionally. Various tools/ are doing that for example.

Not sure what Kbuild thinks about that -- we have a small risk of
breaking things with newer compilers, but that may be not too bad for
just hostprogs (unlike when it was attempted to make it default `y`).

(For Rust, the rate of new releases is very high compared to GCC or
LLVM, but on the other hand it is easy to test them in advance, and
what I have done so far for other things is just clean them as they
appear -- so that should be fine, but it does make it way more urgent
if they are errors every time, though, since it blocks other testing
too).

Cheers,
Miguel

On Tue, Aug 12, 2025 at 12:50:44PM +0200, Miguel Ojeda wrote:
> On Tue, Aug 12, 2025 at 12:25 PM Thomas Weißschuh
> > Another possibility would be to use -Werror
> > for hostprogs unconditionally. Various tools/ are doing that for example.
> 
> Not sure what Kbuild thinks about that -- we have a small risk of
> breaking things with newer compilers, but that may be not too bad for
> just hostprogs (unlike when it was attempted to make it default `y`).
...
> appear -- so that should be fine, but it does make it way more urgent
> if they are errors every time, though, since it blocks other testing
> too).

Yeah I am conflicted. On the one hand, KBUILD_HOSTCFLAGS only has -Wall
and a couple of extra warnings so the risk of new warnings breaking the
build is pretty low. You can see the rate at which warnings get added or
removed from -Wall in clang in the warning-wall.c test:

  https://github.com/llvm/llvm-project/commits/main/clang/test/Misc/warning-wall.c

I'm obviously on top of testing upstream LLVM against hostprogs because
LLVM= makes it easy to set HOSTCC. I suspect that GCC trunk sees less
testing against the hostprogs unless the user has it in their PATH
somehow.

On the other hand, the recent changes to -Wuninitialized and the
addition of -Wuninitialized-const-pointer were extremely disruptive only
because of -Werror... I would have no problems with fast tracking fixes
for hostprogs -Werror usage but I am not sure all maintainers will. This
would also impact vendored host programs like dtc, which may be harder
to update.

We could try it for a development cycle in -next to see if anything gets
noticed. Always easy to back out retrospectively as well. Alternatively,
we could just recommend people use HOSTCFLAGS=-Werror if they desire it.

Cheers,
Nathan