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

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