From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Simon Glass <sjg@chromium.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: u-boot@lists.denx.de,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
AKASHI Takahiro <akashi.tkhro@gmail.com>,
Bin Meng <bmeng.cn@gmail.com>
Subject: Re: enabling W=1 by default
Date: Mon, 21 Oct 2024 19:07:43 +0200 [thread overview]
Message-ID: <5cea49dd-b67e-428e-9ccd-ef16036a53e1@gmx.de> (raw)
In-Reply-To: <CAFLszTjuodDFZW8fJDL1Q3nByLVzcTTEAeJfws-sbtupCwNd8w@mail.gmail.com>
On 10/21/24 18:32, Simon Glass wrote:
> Hi Andy,
>
> On Mon, 21 Oct 2024 at 16:27, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>>
>> Hi!
>>
>> 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...if you would like to enable it for CI
> that is fine by me, but the U-Boot makefile shouldn't do it. It
> defeats the purpose of having a distinction between errors and
> warnings.
>
> Regards,
> Simon
Most contributors don't have access to our CI.
doc/develop/sending_patches.rst does not indicate that patches leading
to build warnings won't be accepted.
We should at least amend the documentation.
Best regards
Heinrich
next prev parent reply other threads:[~2024-10-21 17:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 14:27 enabling W=1 by default Andy Shevchenko
2024-10-21 16:32 ` Simon Glass
2024-10-21 17:07 ` Heinrich Schuchardt [this message]
2024-10-23 22:56 ` Tom Rini
2024-10-22 13:23 ` Andy Shevchenko
2024-10-22 18:13 ` Simon Glass
2024-10-23 23:00 ` Tom Rini
2024-10-23 7:52 ` Alexander Dahl
2024-10-23 14:52 ` Andy Shevchenko
2024-10-26 8:10 ` Ilias Apalodimas
2024-10-28 7:56 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5cea49dd-b67e-428e-9ccd-ef16036a53e1@gmx.de \
--to=xypron.glpk@gmx.de \
--cc=akashi.tkhro@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bmeng.cn@gmail.com \
--cc=ilias.apalodimas@linaro.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.