On 18-08-17 16:51, Nathan Rossi wrote:
On 18 August 2017 at 19:22, Mike Looijmans <mike.looijm...@topic.nl> wrote:
On 17-08-17 23:57, Nathan Rossi wrote:
On 17 August 2017 at 23:12, Mike Looijmans <mike.looijm...@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.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
