Re: Yocto style guide change proposal

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-07-20 at 06:57 -0700, Chris Larson wrote:
> On Fri, Jul 20, 2012 at 6:56 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Fri, 2012-07-20 at 11:32 +0200, Martin Jansa wrote:
> >> Now we have horrible mixture of whitespaces (tabs and space) only in
> >> recipe files, because yocto style guide recommends tabs in shell
> >> functions. So if recipe has e.g. do_install_append as well as
> >> populate_packages_prepend (not so uncommon combination as tabs fixing
> >> patches show), then according to yocto style guide it should look like
> >> this:
> >>
> >> do_install_append() {
> >>       foo
> >> }
> >> python populate_packages_prepend () {
> >>     libdir = bb.data.expand('${libdir}', d)
> >>     do_split_packages(d, libdir, '^lib(.*)\.so\.*', 'lib%s', 'ORC %s library', extra_depends='', allow_links=True)
> >> }
> >>
> >> especially with default tab width 8 spaces it's ugly and because it
> >> is inconsistent, many devs used spaces in shell functions too. Now when
> >> someone accidentaly use tab also in python function it will show warning
> >> or fail to parse. Some devs are using mix of tabs and spaces even on the
> >> same line (e.g. to indent SRC_URI multiline entries).
> >
> > We've said tabs for shell functions for *years*. I'm sure if I were to
> > look at the mailing list archives, that would be clear.
> >
> > In summary, I agree we need to make the style guides consistent and have
> > one version of them. I disagree with spaces for everything though,m
> > particularly as we have said to use tabs for as long and many of the
> > recipes do this (certainly more than use spaces).
> 
> I don't think history is a particularly good reason to keep our
> metadata inconsistent, especially with bitbake becoming picky about
> it.

I don't see it as inconsistent. I think python needed some special
handling since the language itself uses whitespace for structure and
we're now following standard python practise and have a way to ensure
some kinds of bugs don't creep in in future. It was already the agreed
convention, it just wasn't getting well followed, or we had some issues
migrating old mixed code to any one format without enforcing one.

The shell functions are not whitespace sensitive, its mainly an
atheistic issue. There is no issue with mixing tabs and spaces in the
same file. Sure some editor macro files are slightly harder to write to
handle that but I don't see that as a pressing reason to change what has
been the agreed convention.

What I really don't want is a ton of patches changing 80% of the shell
functions. The python changes at least were limited to a smaller subset
of files, mostly core class ones with the majority being
package.bbclass. If we change the shell convention like this, we're in
for orders of mangitiude more changes for no good reason as far as I can
see. The number of functions out there which are whitespace indented
right now is small as far as I can see.

Cheers,

Richard