[yocto] kernel change detection for packages that depend on kernel version?
I'm running into an issue where the branch for my kernel received some new commits, changing what the kernel version string looks like. When I rebuilt my system (bitbake my-image) the kernel was rebuilt (I believe at some point I probably also ran bitbake virtual/kernel -c clean), however several OOT kernel module packages were not rebuilt (one of our modules, as well as lttng-modules). In addition, I have the kernel-devsrc package included in my TOOLCHAIN_TARGET_TASK, and running "... -c populate_sdk" seems to have built an SDK containing the old kernel source. Cleaning those recipes allowed them to rebuild properly, but it seems like rebuilding should have happened automatically... My image recipe looks like this (very abbreviated): inherit core-image IMAGE_INSTALL_append = " packagegroup-core-boot kernel-modules my-oot-module" IMAGE_FEATURES += "package-management" TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc" This brings me to my questions: 1. How do recipes that depend on the kernel headers tell when they need to rebuild? Is there something wrong with my kernel recipe? (for reference, I'm using this one: https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux/linux-altera-ltsi-rt_3.10.bb) 2. Why didn't kernel-devsrc rebuild after the kernel changed? 3. How do I clean the populate_sdk output? Will do_clean clean the populate_sdk output as well? I know I can force it to rerun with "... -f -c populate_sdk" Thanks for your help, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk and kernel headers
Ok, adding kernel-devsrc to my IMAGE_INSTALL caused the kernel source to be included in the SDK. Unfortunately, it is now also included in the target image. I found adding kernel-devsrc instead to TOOLCHAIN_TARGET_TASK gave me what I wanted (/usr/src/kernel in the SDK but NOT in the target image) Also, I really only need the kernel headers (similar to the linux-headers packages in Ubuntu) for developing out-of-source kernel modules. Is there is a different package I should be using? Thanks, Ben -Original Message- From: Andre McCurdy [mailto:armccu...@gmail.com] Sent: Tuesday, July 07, 2015 5:54 PM To: Benjamin Fleming Cc: yocto@yoctoproject.org Subject: Re: [yocto] populate_sdk and kernel headers On Tue, Jul 7, 2015 at 4:16 PM, Benjamin Fleming bflem...@meteorcomm.com wrote: Hello, I want my kernel headers to be included in the SDK output when I run bitbake myimage -c populate_sdk. I expect to see the headers in my installed SDK folder such as sdk/sysroot/target_mach/usr/src/kernel; however, I don't see anything there. Also, I don't want the headers appearing on the target. In my recipe I have added IMAGE_INSTALL += kernel-modules, and SDKIMAGE_FEATURES += kernel-devsrc. The kernel I'm using is linux-altera-ltsi-rt from https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux/l inux-altera-ltsi-rt_3.10.bb What am I missing? Try adding kernel-devsrc to IMAGE_INSTALL rather than SDKIMAGE_FEATURES. Thanks, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk and kernel headers
Ok, Well I can live with the complete source being in the SDK. Thank you for the help -Ben -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Wednesday, July 08, 2015 10:20 AM To: Benjamin Fleming; Andre McCurdy Cc: yocto@yoctoproject.org Subject: Re: [yocto] populate_sdk and kernel headers On 2015-07-08 1:05 PM, Benjamin Fleming wrote: Ok, adding kernel-devsrc to my IMAGE_INSTALL caused the kernel source to be included in the SDK. Unfortunately, it is now also included in the target image. I found adding kernel-devsrc instead to TOOLCHAIN_TARGET_TASK gave me what I wanted (/usr/src/kernel in the SDK but NOT in the target image) Also, I really only need the kernel headers (similar to the linux-headers packages in Ubuntu) for developing out-of-source kernel modules. Is there is a different package I should be using? The linux-libc-headers are the uapi exported headers, but as for the source for module builds, it is currently unified in the kernel-devsrc package. We have a long history with the packaging of the sources, and what to export where .. and even the ordering of that packaging. So while splitting out the headers may seem simple, it requires a bit more finesse of getting the headers, the right amount of script and Kbuild support to get it exactly right. By keeping the two together, we ensure that we have enough to meet all development tasks. There are some enhancements for this in flight for the 1.9 release, so it is something that we are considering .. just keeping those existing use cases and workflows from breaking is the sticky part. Cheers, Bruce Thanks, Ben -Original Message- From: Andre McCurdy [mailto:armccu...@gmail.com] Sent: Tuesday, July 07, 2015 5:54 PM To: Benjamin Fleming Cc: yocto@yoctoproject.org Subject: Re: [yocto] populate_sdk and kernel headers On Tue, Jul 7, 2015 at 4:16 PM, Benjamin Fleming bflem...@meteorcomm.com wrote: Hello, I want my kernel headers to be included in the SDK output when I run bitbake myimage -c populate_sdk. I expect to see the headers in my installed SDK folder such as sdk/sysroot/target_mach/usr/src/kernel; however, I don't see anything there. Also, I don't want the headers appearing on the target. In my recipe I have added IMAGE_INSTALL += kernel-modules, and SDKIMAGE_FEATURES += kernel-devsrc. The kernel I'm using is linux-altera-ltsi-rt from https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux /l inux-altera-ltsi-rt_3.10.bb What am I missing? Try adding kernel-devsrc to IMAGE_INSTALL rather than SDKIMAGE_FEATURES. Thanks, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk and kernel headers
Hello, I want my kernel headers to be included in the SDK output when I run bitbake myimage -c populate_sdk. I expect to see the headers in my installed SDK folder such as sdk/sysroot/target_mach/usr/src/kernel; however, I don't see anything there. Also, I don't want the headers appearing on the target. In my recipe I have added IMAGE_INSTALL += kernel-modules, and SDKIMAGE_FEATURES += kernel-devsrc. The kernel I'm using is linux-altera-ltsi-rt from https://github.com/kraj/meta-altera/blob/master/recipes-kernel/linux/linux-altera-ltsi-rt_3.10.bb What am I missing? Thanks, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CMake in populate_sdk
-Original Message- From: Philip Balister [mailto:phi...@balister.org] Sent: Tuesday, January 20, 2015 5:29 PM To: Benjamin Fleming; yocto@yoctoproject.org Subject: Re: [yocto] CMake in populate_sdk On 01/20/2015 02:42 PM, Benjamin Fleming wrote: How do I add packages to the populate_sdk option? Something like this: https://github.com/balister/meta-sdr/blob/master/recipes- images/images/native-sdk.inc Ok, adding TOOLCHAIN_HOST_TASK_append = nativesdk-cmake seems to work; it adds cmake to the SDK. One more question; when building using the SDK, my cmake-based project fails to find required libraries; presumably it needs a toolchain.cmake file. Is there some way for the populate_sdk task to generate the toolchain.cmake files also? (I see that it generates something for autotools) Thanks, Ben Philip -Ben Fleming -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] CMake in populate_sdk
How do I add packages to the populate_sdk option? I have an image (myimage) that depends on some custom packages which inherit the cmake bbclass. My expectation is that the populate_sdk task would notice that cmake is required for building and, as a result add cmake to the SDK. That is not the case. Also, for some reason, make is not included, either: $ source /opt/poky/1.6.2/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi $ which automake /opt/poky/1.6.2/sysroots/x86_64-pokysdk-linux/usr/bin/automake $ which make usr/bin/make What should I be adding to cause the inclusion of CMake in the SDK output? -Ben Fleming -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse ADT plugin and project variables
I have the Yocto 1.6.1 Eclipse ADT plugin installed in the ARM DS-5 (5.18) platform (based on Eclipse Kepler). After some struggling, I have been able to generate a CMake-based project that build successfully, but it has left me with 2 related questions. The first is specification of the cmake executable: The plugin won't use the correct PATH variable when calling CMake: Under Project-Properties...-C/C++ Build-Settings-CMake configure, the default command is 'cmake', which for me finds the wrong copy on my system. I have 2 copies of cmake on my system, the first is installed under /usr/bin/, and the second (and the one I want to use) is under my poky tree (~/poky/build/tmp/sysroots/x86_64-linux/usr/bin/). The PATH in my project environment variables (Project-Properties...-C/C++ Build-Environment) points to the sysroots path first, and indeed, if I create a shellscript that defines the same path it finds the expected cmake executable. To make this work currently, I have to enter the absolute path to the appropriate binary, which seems wrong. This leads me to my second question; what is the expected method of sharing projects? I don't see a way to easily share my .project and .cproject files with my coworkers while allowing them to use my ADT plugin settings. My poky build directory (including sysroots) is in my home directory. As a result, many of the Environment variables refer to a path containing my home directory. Perhaps this is just my ignorance of Eclipse, but I don't see a good way of sharing the setup work without a) asking them to import my project and then modifying around 25 paths, or b) asking them to create a new hello world project in which they then have to overwrite files. How do I go about sharing the project files? Regards, Ben -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
