Re: [PATCH] bitbake: parse: allow vars_from_file to consider inc files as recipes

[Joe MacDonald <joe@deserted.net>]

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]

[Re: [bitbake-devel] [PATCH] bitbake: parse: allow vars_from_file to consider inc files as recipes] On 14.04.01 (Tue 14:56) Richard Purdie wrote:

> On Tue, 2014-04-01 at 09:50 -0400, Joe MacDonald wrote:
> > > On Mon, 2014-03-31 at 16:44 -0400, joe@deserted.net wrote:
> 
> > I don't want to keep using meta-selinux as an example here, (since it
> > mostly ends up looking bad for meta-selinux, I suppose) but I can
> > actually see a case where -common would be organizationally desirable.
> > Or at least not ugly.  recipies-security/selinux has a collection of
> > core selinux recipes, each has their own patches directory which
> > potentially co-mingles patches for versioned and git-based recipes or
> > both.  Right now none of the recipes in there are doing the
> > <specific> -> <versioned> -> <common> include thing, but it's not a huge
> > stretch to imagine it being useful.
> > 
> > In other cases that'd be done with a versioned directory name and a
> > files/ directory, but that would make things less clear, not more in
> > this scenario.  So having a <recipie>-common directory would be kind of
> > good.
> 
> Well, you can do that, but you should name it as such in the variable,
> not abuse the PV variable like this! :)
> 
> > > I'd therefore much rather figure out what is happening to cause the
> > > expansion of PV in the .inc file and see if we can't avoid that.
> > > 
> > > Looking at the layer, the issue is:
> > > 
> > > FILESEXTRAPATHS_prepend := "${THISDIR}/refpolicy-${PV}:"
> > > 
> > > and I'd suggest that line move to the .bb files in this case.
> > 
> > That's what I'll do if you're not convinced on this patch, but when I
> > started down that path yesterday afternoon I got thinking about what I'd
> > laid out above and that I would be duplicating the exact same line in
> > three recipes right now (-mcs, -mls and -standard) and adding it to any
> > other new policies that get submitted.  That really is a common piece
> > shared among all the variants and it seemed like the right thing to do
> > was have it only in one place.
> 
> I understand the concern there, you could do this with a "common" name
> in the variable instead of PV though.

Sure, but implementing that solution here amounts to having two
variables (well, one for now, but potentially adding a second one down
the road for functionality that would otherwise have been a beneficial
side effect of variable expansion) one of which contains ${PV}.  That
was actually the very first thing I did in tracking this back to the
source, but that really seemed like a wink and a nod and I frankly felt
kind of dumb for doing something that I could already get from ${PV}.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]