[U-Boot] [PATCH] config.mk: Add -Wundef to CFLAGS

[Albert ARIBAUD]

Hi Masahiro,

On Wed, 21 Aug 2013 13:33:19 +0900, Masahiro Yamada
<yamada.m at jp.panasonic.com> wrote:

> Hello, Albert and U-Boot developers.
> 
> 
> The current status of this patch is Changes Requested.
> 
> I love -Wundef option to be in, but it looks like
> difficult for me to post the version 2.
> 
> 
> The first choice to meet Albert's requirement is
> 
> > Therefore I ask:
> > 
> > - that this patch be submitted along fixes to build failures it
> >   causes, as a proper patch series, by a single individual,
> 
> Sorry, I cannot do this because:
> 
> I am not familiar with architectures other than ARM.
> I understand only a few devices.
> To fix warnings in a correct way, a close look is often needed,
> but I cannot cover the whole code in the U-Boot tree.
> 
> If possible, could anyone take over this task?
> 
> 
> 
> The other option is
> 
> >   collected by someone in an officially created git repo or branch;
> 
> OK, I can do this.
> But I am not sure this will go well.
> 
> Even if I create a new repo u-boot-wundef,
> how many people will pay attention to this repository?
> 
> Most of users/developers track upstream repos
> where -Wundef warnings are never displayed.
> 
> This means no one will have the motivation to fix the warnings.
> 
> 
> 
> If this patch is desired, in which way should we continue?
> Comments are welcome.

Sorry not to have followed up earlier.

As I said, I want fixes for trivial cases -- cases where, for instance,
a macro is used in an #if which has absolutely *no* definition in the
whole codebase. I do not want fixes for all cases.

OTOH, to find out which failures would be trivial to fix and which ones
would not, you'd have to go through all of them, which could be
time-consuming, depending on the number of targets.

I thus suggest we use the typical U-Boot strategy: right at the
beginning of the merge period, we apply the -Wundef patch onto all
repos (or on the main repo and then pulled into others) and then wait
for screams.

Screams should come fst from custodians, who routinely build for all
targets of their assigned architecture. They will see which boards fail
due to undefined macros and will report those failures on the list,
copying the board maintainers (or subsystem owners if the issue is not
board-specific.

All boards not fixed before merge window closure release will be
declared dying; all those not fixed before 2014.01 will be declared
dead, and orphaned and put in the scrapyard (and then, people who want
them back can always resurrect *and fix* them).

Subsystems... will have to be fixed some way or other.

Of course, anyone with an interest can spontaneously provide fixes for
boards or subsystems affected.

Adding Tom and Wolfgang for advice, but of course comments are welcome
from everyone.

> Best Regards,
> Masahiro Yamada

Amicalement,
-- 
Albert.