From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Sat, 2 Dec 2017 14:10:59 +0100 Subject: [Buildroot] [PATCH 1/1] check-package: avoid false warning of useless flag In-Reply-To: <20171202110320.GA2988@scaer> References: <1512188904-31366-1-git-send-email-ricardo.martincoski@datacom.ind.br> <20171202110320.GA2988@scaer> Message-ID: <20171202141059.391df6c0@windsurf.lan> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hello, On Sat, 2 Dec 2017 12:03:20 +0100, Yann E. MORIN wrote: > > Instead of increasing complexity of the script to fully detect this > > case, ignore the host flag set to its default value as it can be > > overriding a non-default value inherited from the equivalent target > > flag. > > But then we miss the cases where: > - both are set to their default values, > - the target one is not set and the host one is set to the default > value. > > But as you said, detecting the real false-positive would require > maintaining some state, which is currently not possible in the script. > > Yet, htere is one issue I see: the script currently names issues mere > 'warnings' but exits with a non-zero error code as soon as at least one > such 'warning' is seen. > > However, what we so far detected were really 'errors', not 'warnings', > while the case we are speaking about now really is a warning: it should > be reported, biut should not exit in error. I'm not sure we want to go down this road, and distinguish warnings and errors. Either something is correct, or it's not. I prefer to have a clean and readable check-package output, with only things that really need to be fixed. > Also I noticed that the comments do match the regexps: > > 288: # We need HOST_ASTERISK_AUTORECONF = NO because the > 289: # target variant has _AUTORECONF = YES > 290: HOST_ASTERISK_AUTORECONF = NO > > will report the issue twice (man URL removed): > > package/asterisk/asterisk.mk:288: useless default value [...] > package/asterisk/asterisk.mk:290: useless default value [...] > > Since this is the .mk parser, it could ignore the comments, I believe... Agreed, but that's a separate issue :) Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com