From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>,
OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] classes: Standardize strings tests, and join some if/then/while/do lines
Date: Tue, 28 Mar 2017 14:25:50 +0000 [thread overview]
Message-ID: <01f71a47963847fbb79bf376b814d551@XBOX02.axis.com> (raw)
In-Reply-To: <alpine.LFD.2.20.1703280641380.4243@uk63952.mitel.com>
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Robert P. J. Day
> Sent: den 28 mars 2017 12:51
> To: OE Core mailing list
> Subject: [OE-core] [PATCH] classes: Standardize strings tests, and join
> some if/then/while/do lines
>
>
> For better or worse, two types of cleanup in meta/classes directory:
>
> * Replace old-style 'x${VAR} = x' tests with -n/-z string tests
> * Unsplit lines to keep if/then, while/do on same line
>
> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
>
> ---
>
> i realize there are two types of tidying here -- if that offends
> people, i can split it into two separate submissions. nothing here
> should affect execution, but it's always possible i screwed something
> up, not sure how to rigourously test these changes.
>
> also, when i did change a shell string test, i added {} around the
> variable name, it's just a standard i like for visual clarity. apply
> all or part of what seems useful.
You should absolutely not do this, especially if you want visual clarity
in a BitBake recipe. This makes the variable look like a BitBake variable
instead of a shell variable, and not just to us humans, but to bitbake
as well. It will cause bitbake to put an unnecessary dependency on the
(typically non-existent) BitBake variable ${VAR} in the state signature
for the shell function. Which, as Ross pointed out, will cause problems
in the case where there actually are both a BitBake variable and a shell
variable with the same name.
In addition to that, you would throw at least our company's shell expert
into a fit if you tried to do that in any shell code at all. ;)
//Peter
next prev parent reply other threads:[~2017-03-28 14:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-28 10:50 [PATCH] classes: Standardize strings tests, and join some if/then/while/do lines Robert P. J. Day
2017-03-28 11:31 ` Burton, Ross
2017-03-28 12:04 ` Robert P. J. Day
2017-03-28 12:18 ` Robert P. J. Day
2017-03-28 12:23 ` Burton, Ross
2017-03-28 14:25 ` Peter Kjellerstedt [this message]
2017-03-28 14:29 ` Robert P. J. Day
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=01f71a47963847fbb79bf376b814d551@XBOX02.axis.com \
--to=peter.kjellerstedt@axis.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=rpjday@crashcourse.ca \
/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.