On Wed, Oct 23, 2024 at 09:52:09AM +0200, Alexander Dahl wrote: > Am Tue, Oct 22, 2024 at 04:23:07PM +0300 schrieb Andy Shevchenko: > > On Mon, Oct 21, 2024 at 06:32:21PM +0200, Simon Glass wrote: > > > On Mon, 21 Oct 2024 at 16:27, Andy Shevchenko > > > <andriy.shevche...@linux.intel.com> wrote: > > > > > > > > looking at the redness of the output of `make W=1` here is the question: > > > > isn't it a good time to enable `make W=1` by default. Yes, I understand > > > > the impact, but at least we can do it mandatory for a _new_ code > > > > submitted to > > > > U-Boot, right? > > > > > > > > Ideally I would have what Linux kernel has for a few releases already, > > > > i.e. > > > > Werror by default and getting close to make a clean builds with that and > > > > make W=1` at least against default configurations (yeah, with U-Boot > > > > there is > > > > probably no default, but sandbox one). > > > > > > Warnings should be warnings... > > > > Yes, and ideally the code should not have warnings, right? > > +1 > > > Otherwise how can we do better? It's quite similar to what you wrote WRT > > documenting the function prototypes, the same applies to the new > > contribution > > WRT `make W=1`. > > > > > if you would like to enable it for CI that is fine by me, > > > > Yes, that's the idea, but I'm not the owner of any U-Boot CIs, > > hence it's a proposal. > > > > > but the U-Boot makefile shouldn't do it. It defeats the purpose of > > > having a distinction between errors and warnings. > > > > While it's not what I wanted, I disagree on your comment. The idea is to > > make > > rules stricter (for new code) to make it better and that's why Linus enabled > > Werror by default in the Linux kernel. And personally I consider that as a > > good > > thing to follow. > > Long term experience: each time you upgrade your toolchain you get new > warnings. Each package (u-boot, kernel, userland, does not matter > which) enabling -Werror breaks the BSP build. What should a developer > do then? Fix each warning in each foreign project and bring it > upstream? Or disable -Werror? Last thing is what is usually done. > You can see several patches in buildroot or ptxdist disabling -Werror > for this reason.
That's why the set of enabled/disabled warnings are spread over W=<n> and hence hidden when known to be PITA. W=1 is kinda special in a sense that we put the warnings that might affect code generation, size of the binary, etc. In some cases it even might prevent security bugs. -- With Best Regards, Andy Shevchenko
