[meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

[Mike Looijmans]

On 18-08-17 16:51, Nathan Rossi wrote:
> On 18 August 2017 at 19:22, Mike Looijmans <mike.looijmans at topic.nl> wrote:
>> On 17-08-17 23:57, Nathan Rossi wrote:
>>>
>>> On 17 August 2017 at 23:12, Mike Looijmans <mike.looijmans at topic.nl>
>>> wrote:
>>>>
>>>> I'm attempting to revive my build for the MPSOC machines. If one does
>>>> something like this:
>>>>
>>>> MACHINE=zcu102-zynqmp bitbake my-image
>>>>
>>>> I get parsing errors like:
>>>>
>>>> ERROR: ExpansionError during parsing /home/mike/projects/@@@.bb
>>>> Traceback (most recent call last):
>>
>> ...
>>>>
>>>> bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
>>>> expression
>>>> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
>>>> Fetcher failure: The SRCREV_FORMAT variable must be set when multiple
>>>> SCMs
>>>> are used.
>>>
>>>
>>> Looks like a very odd failure, unfortunately I cannot reproduce with
>>> pyro or master on recipes that use version control or dynamic SRCREV
>>> features. Could you provide some build config info and if possible the
>>> recipe that is generating the error?
>>
>>
>> I made a "bare" clone of oe-core, meta-oe and meta-xilinx. Ran a build,
>> which went okay.
>>
>> I copied this recipe into meta-xilinx for parsing, and got the error:
>>
>> (topic-miami-monitor-lib.bb, fetches a C program from github)
>>
>> ...
>>
>> SUMMARY = "Example and/or library for reading SOM monitor devices"
>> LICENSE = "GPLv3"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=9eef91148a9b14ec7f9df333daebc746"
>>
>>
>> GITHUB_TOPIC_URI ?= "git://github.com/topic-embedded-products"
>> SRC_URI = "${GITHUB_TOPIC_URI}/${PN}"
> 
> Ah, there is the issue. PN, which is modified for
> native/nativesdk/multilib/"zynqmp-pmu" class extenders.
> 
> So what happens is that for the normal target parsing PN="foo", but
> when it parses with the extended classes PN="zynqmp-pmu-foo" (or
> similar) for those. Which results in multiple SRC_URI's. Using "PN" in
> something like the SRC_URI is probably going to cause pain in other
> ways too. Most recipes use BPN to get the name of the recipe, there
> are a few that use PN though in meta-oe at least but they don't enable
> any classextenders (and none of them use git src_uris).

I missed that memo on the BPN introduction I guess :)

Anyway, it'd be a good thing to replace PN in these recipes by BPN. That 
I'll do for sure.

> I will make a patch to have the zynqmp-pmu config only extend the used
> recipes (gcc/etc.), I had not figured out a good way to do it
> previously, but have a sane solution to that now. However I would
> still recommend you avoid using PN in the way you have.

I tried something similar using something like:
  BBCLASSEXTEND_pn-gcc_append
but that didn't quite work for some packages.

> https://github.com/nathanrossi/meta-xilinx/commit/2d462040fdcadda70e08a5568f1c9217ea7e0624

Are you aware that this commit drops the "PACKAGE_EXTRA_ARCHS_append" 
assignment?


> Will post it on list after some testing, specifically with pyro so it
> can be backported to that branch too.

I'll test along...

Kind regards,
-- 
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail