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

[Richard Purdie]

On Tue, 2014-04-01 at 09:50 -0400, Joe MacDonald wrote:
> > On Mon, 2014-03-31 at 16:44 -0400, joe at 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.

Cheers,

Richard