PV from filename, not reflected in siginfo?

Hi,

I'm currently investigating reports of bitbake not correctly handling a type of change to a recipe, where the only change is a filename rename to update the PV.

With bitbake-dumpsigs:

...
Variable PV value is ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'} Variable PN value is ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}
...

... with nothing containing the resolved value of PV. I would expect the computed value of PV to be a part of the siginfo. The consquence of this seems to be that bitbake doesn't schedule dependents to be rebuilt, i.e. if I rename the recipe foo_1.2.3.bb to foo_1.2.4.bb, the recipe foo is rebuilt, but the image isn't.

I tried some changes:

- Changing the PV assignment in bitbake.conf to :=. Didn't work, got errors that I suspect are related to not being able to include foo-${PV}.inc files. The value of PV was clobbered. Also played around with using BB_FILENAME instead, but didn't help.

- Changes within Bitbake that assigned the version part of the filename to PV when loading new files ending with .bb. This worked but is really ugly.

- Moving the PV assignment into the recipe (as an explicit assignment). This works, makes dependents build as expected and bitbake-dumpsigs lists the value, but is also ugly.

I suspect this isn't usually a problem in OE-Core, since most recipe updates requires updates within the recipe as well (tarball checksums, for instance), but that's not as true for our internal recipes.

Is this a known issue? Any ideas on how to solve this? Nicer workarounds?

Thanks,

olofjn

It isn't known but I can imagine how this could cause a problem.

I suspect (but am guessing) that:

PV[vardepvalue] = "${PV}"

might happen to fix this...

Cheers,

Richard

...

Indeed, that works! Thanks a lot! It's not completely obvious to me why it works, but I'm guessing that this is just a way to make sure PV is expanded before siginfo is dumped?

Is something based on this acceptable for integration in oe-core, or is this just a (much) nicer workaround?

olofjn