On 4/27/2018 5:34 PM, Andre McCurdy wrote:
On Fri, Apr 27, 2018 at 3:44 AM, Damien LEFEVRE <[email protected]> wrote:Hi, This must be a stupid basic question. I have the following recipe append: keymaps_1.0.bbappend ----------------------------------------------------------------------------- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI_append = " file://keymaps.service \ file://keymap.sh \ " do_install_append() { install -d ${D}${sysconfdir} ln -sf /usr/share/keymaps/i386/qwerty/fi.map.gz ${D}${sysconfdir}/keymap-${LINUX_VERSION}.map.gz install -d ${D}${systemd_system_unitdir} install -m 0644 ${WORKDIR}/keymaps.service ${D}${systemd_system_unitdir} } FILES_${PN} += " ${sysconfdir}/* \ ${systemd_system_unitdir}/* \ " inherit systemd SYSTEMD_SERVICE_${PN} = "${PN}.service" ----------------------------------------------------------------------------- The LINUX_VERSION is not expanded and the final symlink name becomes /etc/keymap-.map.gz. What's correct way to get the linux version in the recipe files?In general, there isn't a correct way to do that. The LINUX_VERSION variable is defined within the kernel recipe and other recipes won't have access to it. A core concept in OE is that recipes build independently of each other. In this case, since the keymaps recipe has no direct dependency on the kernel, you should not expect the keymaps recipe to be rebuilt (or affected in any way) when the kernel or kernel version changes.
Yep. Unless you inherit the kernel build classes there's no easy way to do this. But if the kernel classes are inherited, then some of the variables like KERNEL_VERSION become available to use .. but of course, you've just tightly coupled things to the kernel. Cheers, Bruce
The keymaps init script ( meta/recipes-bsp/keymaps/files/keymap.sh ) detects the kernel version dynamically at runtime. If you need a kernel version specific symlink in your target rootfs, maybe you could create it at runtime from your keymaps service file?
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
