On 15-03-10 09:49 AM, Jeff Melville wrote:
I'm using a Yocto flow to build for the Zynq with the meta-xilinx with
some customizations:
- I'm using a bbappend to replace the linux-xlnx 3.14 kernel with one
that has had mainline changes from 3.14.17 merged in.
- I added a task between patch and configure for applying the Xenomai
kernel patches and running the Xenomai prepare_kernel script.
All layers are on the dizzy branch. The linux-xlnx recipe inherits
from linux-yocto but obtains the metadeta from an out of tree source
using a SRC_URI append with type=kmeta. This ends up getting copied
into the kernel tree with during the kernel_configme task. This is my
first time working with a kernel recipe in the linux-yocto style so
I'm still coming up to speed a bit.
The problem arises because the Xenomai patch process creates
additional directories in the Linux tree. As part of the
kernel_configme task, the kgit-meta script will attempt to use the
last unversioned directory returned by 'git ls-files -o --directory'
as the metadata directory, which does not work.
Two questions:
1) What is the best short term way for me to work around this?
Write a _append to the do_kernel_checkout that removes the extra
directories. But since I have no idea what the directories are
used for .. that may or may not be a good thing.
2) Is there a way to patch the meta directory detection in kgit-meta
to make it more robust against false detections?
Its software, so everything is possible :) But that code was written to
free ourselves from being locked to the meta-data directory needing
to match the meta-data repo/branch name, and to not introduce yet
another arcane variable to the build process.
If I tweak this yet again, other use cases will potentially break, so
it has to be carefully done.
I have some ideas on how to do this though .. can you open an
enhancement request in the yocto bugzilla and assign it to me ?
Cheers,
Bruce
Thanks,
Jeff
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
