Incredibly sorry for top-posting, but a build history diff should show any delta and assuming none will give a lot more confidence in the changes being complete. In theory a simple change of indentation shouldn't result in any changes to the image, right?

Ross
-- 
Ross Burton
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Wednesday, 11 July 2012 at 18:36, Richard Purdie wrote:

> On Wed, 2012-07-11 at 11:33 -0500, Peter Seebach wrote:
> > On Wed, 11 Jul 2012 17:12:29 +0100
> > Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > 
> > > I think I at least would find this slightly less confusing as:
> > > 
> > > workparentdir = d.getVar("DEBUGSRC_OVERRIDE_PATH", True) or
> > > os.path.dirname(workdir)
> > > 
> > 
> > 
> > Wait, LESS confusing?
> > 
> > I appear to have tragically misunderstood the design goals of
> > package.bbclass. :P
> > 
> 
> 
> Well, we are trying over time... :)
> 
> > But yes, that's a good improvement. Applied locally.
> > 
> > Speaking of confusing: If purely hypothetically I wanted to
> > submit a patch which standardized the indentation in package.bbclass,
> > would anyone be interested in that? I ask only because while I can
> > accept either 8-space or 4-space indentation, I find it comforting when
> > any given file full of Python source uses one or the other.
> > 
> 
> 
> It should all use 4 space for python functions. There is however a twist
> which is due to the way we handle _prepend and _append. Those prepends
> and appends have whitespace too and I seem to remember issues with
> whitespace matching.
> 
> Yes, this is horrible. This is why that file hasn't been touched for
> whitespace though.
> 
> > And while there's currently only a couple of blocks of 4-space
> > indentation in the file, we *normally* use 4-space, that's the
> > quasi-official Python community norm, and a LOT of the "too long" lines
> > in that file would be much more readable at 4 spaces.
> > 
> > (This would be a totally separate patch, and I'm not super happy about
> > the idea of a patch which updates half or more of the lines in the
> > file, but it's not as though it'll be less painful to fix later.)
> > 
> 
> 
> I'd be interested to see how much breakage we get from changing it. In
> fact I just tried it, the result:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t14&id=3db917bfb2455715a3a3a542ea831d05ca1cf9f7
> 
> the particularly nasty bit:
> 
> python populate_packages () {
> # Whitespace is deliberately a tab here due to the number of packages which
> # prepend this fuction :(
> populate_packages_core(d)
> }
> 
> other than that it does seem to be working as long as I tweaked the
> busybox recipe and update-alternatives too. We could go through and
> change all the populate_packages_prepend functions but its the ones
> outside OE-Core I worry about. I also worry there are some _append
> functions now silently failing though :(.
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
>