From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Joe MacDonald <Joe.MacDonald@windriver.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH] recipes: Unify indentation
Date: Mon, 15 Apr 2013 14:13:51 +0100 [thread overview]
Message-ID: <85380742.XfAzseB4Gc@helios> (raw)
In-Reply-To: <20130415124259.GI3914@windriver.com>
On Monday 15 April 2013 08:42:59 Joe MacDonald wrote:
> [Re: [oe] [meta-oe][PATCH] recipes: Unify indentation] On 13.04.14 (Sun
18:30) Koen Kooi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Op 14-04-13 00:12, Martin Jansa schreef:
> > > * This change is only aesthetic (unlike indentation in Python tasks). *
> > > Some recipes were using tabs. * Some were using 8 spaces. * Some were
> > > using mix or different number of spaces. * Make them consistently use 4
> > > spaces everywhere. * Yocto styleguide advises to use tabs (but the only
> > > reason to keep tabs is the need to update a lot of recipes). Lately this
> > > advice was also merged into the styleguide on the OE wiki. * Using 4
> > > spaces in both types of tasks is better because it's less error prone
> > > when someone is not sure if e.g. do_generate_toolchain_file() is Python
> > > or shell task and also allows to highlight every tab used in .bb, .inc,
> > > .bbappend, .bbclass as potentially bad (shouldn't be used for indenting
> > > of multiline variable assignments and cannot be used for Python tasks).
> > >
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >
> > I still hate spaces for shell methods, but I support the reasons behind
> > it, so:
> >
> > Acked-by: Koen Kooi <koen@dominion.thruhere.net>
>
> I completely agree. The only spot where I see this as being not optimal
> is something like this (hunk simplified for clarity):
>
> PACKAGES += "${PN}-ndisc6 ${PN}-tcpspray6 ${PN}-rdisc6 \
> - ${PN}-tcptraceroute6 ${PN}-rltraceroute6 \
> - ${PN}-tracert6 ${PN}-rdnssd ${PN}-misc"
> + ${PN}-tcptraceroute6 ${PN}-rltraceroute6 \
> + ${PN}-tracert6 ${PN}-rdnssd ${PN}-misc"
>
> The former state wasn't great, but in general if I'm doing this type of
> thing, I'll tend to align them thus:
>
> PACKAGES += "${PN}-ndisc6 ${PN}-tcpspray6 ${PN}-rdisc6 \
> ${PN}-tcptraceroute6 ${PN}-rltraceroute6 \
> ${PN}-tracert6 ${PN}-rdnssd ${PN}-misc"
>
> Probably leaving such things as they are in the tree is more trouble
> than it's worth, but we could, I'd like to avoid restyling after a line
> continuation. I won't object to the proposal as it stands, though,
> since on the whole it looks to be doing much more good than harm.
It has always been considered best practice to indent multi-line variables in
the latter way with spaces only - however this is separate from the
indentation being used within scripts.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2013-04-15 13:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 13:46 Consistent indentation in meta-openembedded metadata Martin Jansa
2013-04-13 20:01 ` Otavio Salvador
2013-04-13 22:12 ` [meta-oe][PATCH] recipes: Unify indentation Martin Jansa
2013-04-14 16:30 ` Koen Kooi
2013-04-15 12:42 ` Joe MacDonald
2013-04-15 13:07 ` Martin Jansa
2013-04-15 13:13 ` Joe MacDonald
2013-04-15 13:13 ` Paul Eggleton [this message]
2013-04-15 18:30 ` Consistent indentation in meta-openembedded metadata Khem Raj
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=85380742.XfAzseB4Gc@helios \
--to=paul.eggleton@linux.intel.com \
--cc=Joe.MacDonald@windriver.com \
--cc=openembedded-devel@lists.openembedded.org \
/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.