Re: [PATCH 1/1] package.bbclass: Allow overriding of debugedit starting path

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

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