[yocto] allarch class used in autoconf-archive recipe
Hi, myself grabbed autoconf-archive recipe from http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb to build and install autoconf archive for building user-space app. autoconf-archive package builds in Jethro, as the YP release used here is, without problems even if grabbed from release later than Jethro. That recipe inherits 'allarch' class. If to review Jethro Reference Manual following note can be found reg. 'allarch' class usage: "Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes that produce packages that depend on tunings through use of the RDEPENDS and TUNE_PKGARCH variables, should never be configured for all architectures using allarch. This is the case even if the recipes do not produce architecture-specific output. Configuring such recipes for all architectures causes the do_package_write_* tasks to have different signatures for the machines with different tunings. Additionally, unnecessary rebuilds occur every time an image for a different MACHINE is built even when the recipe never changes." Same note is to be found on reference manual's master branch. Few questions arise from that: 1. What might be best solution to the discrepancy "not recommended to use vs. used in OE-recipe"; to drop this inheritance? 2. How might recipe's past change-flow resulting in recipe's current version to inherit 'allarch' class look like? This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] inheriting native.bbclass explicitly
Hi, YP reference manual chapter 6.83 "native.bbclass" https://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#ref-classes-native reads: "*Create a myrecipe-native.bb that inherits the native class. If you use this method, you must order the inherit statement in the recipe after all other inherit statements so that the native class is inherited last." Is this rule's scope literally each single recipe separately or rather the compound .bb file + set of matching .bbappends? I am going to use that method for building autoconf-archive package as for device built here this package is needed only on build system and in no case on target system. Regards krzysiek This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] inheriting native.bbclass explicitly -- more details
autconf-archive's recipe as for OE-core layer builts also native package in BBCLASSEXTEND-based fashion. I like for system built here to change the approach to explicit-class-inheritance fashion in .bbappend in own layer. Will it suffice to ensure native.bbclass is explicitly inherited as last class in .bbappend? This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inheriting native.bbclass explicitly
Thanks for feedback from you. > If you use BBCLASSEXTEND (ie "the second method") then that recipe naming > rule doesn't apply. Looks like section's 6.83 current structure wouldn't reflect this fact well. Warning is placed directly below one-sentence and indented text describing to BBCLASSEXTEND-case krzysiek -Original Message- From: Andre McCurdy [mailto:armccu...@gmail.com] Sent: Friday, 14. September 2018 01:05 To: Dudziak Krzysztof Cc: Burton, Ross ; yocto@yoctoproject.org Subject: Re: [yocto] inheriting native.bbclass explicitly On Thu, Sep 13, 2018 at 6:05 AM, Dudziak Krzysztof wrote: > Current release's reference manual issues in native.bbclass chapter a warning: > "When creating a recipe, you must follow this naming convention: > native-myrecipe.bb > Not doing so can lead to subtle problems because code exists that depends on > the naming convention." Looks like a mistake in the documentation. Native only recipes (ie recipes which use "inherit native" rather than BBCLASSEXTEND) should have "-native" as a suffix, not "native-" as a prefix. > Jethro release manual does not point it out. > Is this warning really out of relevance for certain past releases e.g. Jethro? > > Abstracting from question raised above how following two fit all together: > "When creating a recipe, you must follow this naming convention: > native-myrecipe.bb" > and > " The advantage of the second method is that you do not need to have > two separate recipes " (2.5.1 Release Reference Manual) If you use BBCLASSEXTEND (ie "the second method") then that recipe naming rule doesn't apply. ie a recipe using BBCLASSEXTEND should not have a "-native" suffix. > krzysiek > > -Original Message- > From: Burton, Ross [mailto:ross.bur...@intel.com] > Sent: Thursday, 13. September 2018 14:00 > To: Dudziak Krzysztof > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] inheriting native.bbclass explicitly > > On 13 September 2018 at 12:39, Dudziak Krzysztof > wrote: >> Thanks for hints. >> I don't want to have this package on target system. >> You sound like inheriting explicitly had some major drawback of wide scope. > > It won't be included in the image unless you add it to the image. > > Ross > > This message and any attachments are intended solely for the addressees and > may contain confidential information. Any unauthorized use or disclosure, > either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission free > from viruses, the sender will not be liable for damages caused by a > transmitted virus. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > ts.yoctoproject.org%2Flistinfo%2Fyoctodata=02%7C01%7CKrzysztof.Du > dziak%40gemalto.com%7Ced60588df01e4484015c08d619cd5ee6%7C37d0a9db7c464 > 096bfe31add5b495d6d%7C1%7C0%7C636724767194372674sdata=8GXUXT5abR3 > BHWxhzbCf0bbYxYqpU7x6r0ZXbQt7clw%3Dreserved=0 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building, Using SDK
Hi, Thanks for feedback from you. Embedded system native package building and image creation might not be the regular case as frequently embedded system do not provide power needed for that. So let's concentrate to cross-compilation. One need first working toolchain. In next steps one can build BSP, user-space, image(-s). Is the sequence of step as presented previously the right one? step 1: bitbake -c populate_sdk step : build bootloader, kernel step : bitbake krzysiek From: ChenQi [mailto:qi.c...@windriver.com] Sent: Monday, 17. September 2018 05:50 To: Dudziak Krzysztof ; yocto@yoctoproject.org Subject: Re: [yocto] Building, Using SDK On 09/13/2018 10:18 PM, Dudziak Krzysztof wrote: Hi, Alex González elaborates in his book Embedded Linux Development Using Yocto Projets (2nd Edition) SDK-related questions - basics, building, usage (chapter 4). 1. Downloading then installing precompiled SDK was one of all available options according to Alex. He elaborates how to find it on server in Internet, how to select needed one and install it. I wonder how to integrate downloaded and installed precompiled SDK to Poky release used on build system? I'd suggest you not using precompiled SDK unless you are justing doing some simple cross compilation that requires no additional libs, header files, etc. 2. Preparing / building SDK by oneself was further option with image target's 'populate_sdk' Bitbake task as the recommended way (according to Alex in chapter's certain section). One would need only to start populate_sdk task for image which matches root file system of system in development. As soon as task completed SDK can be installed using generated script. But how does it work for first build where rootfs was not built in the past. Is in that case following procedure the proper one? step 1: bitbake -c populate_sdk step 2: bitbake The populate_sdk task directly installs rpm packages (nativesdk ones and target ones) to form an SDK. It does not need rootfs to be generated first. Normally you use an SDK for a specific target. So the `bitbake IMAGE' is used to generate the image, and `bitbake IMAGE -c populate_sdk' is used to generate the SDK for the image. Best Regards, Chen Qi krzysiek This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inheriting native.bbclass explicitly
Current release's reference manual issues in native.bbclass chapter a warning: "When creating a recipe, you must follow this naming convention: native-myrecipe.bb Not doing so can lead to subtle problems because code exists that depends on the naming convention." Jethro release manual does not point it out. Is this warning really out of relevance for certain past releases e.g. Jethro? Abstracting from question raised above how following two fit all together: "When creating a recipe, you must follow this naming convention: native-myrecipe.bb" and " The advantage of the second method is that you do not need to have two separate recipes " (2.5.1 Release Reference Manual) krzysiek -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Thursday, 13. September 2018 14:00 To: Dudziak Krzysztof Cc: yocto@yoctoproject.org Subject: Re: [yocto] inheriting native.bbclass explicitly On 13 September 2018 at 12:39, Dudziak Krzysztof wrote: > Thanks for hints. > I don't want to have this package on target system. > You sound like inheriting explicitly had some major drawback of wide scope. It won't be included in the image unless you add it to the image. Ross This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inheriting native.bbclass explicitly
Thanks for hints. I don't want to have this package on target system. You sound like inheriting explicitly had some major drawback of wide scope. I am familiarized with bitbake -e I know it as a way to print package/image tasks variables. But how its output shows the list of classes inherited and the order they are inherited by Bitbake target? Is any variable indicating this included in its output? krzysiek -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Thursday, 13. September 2018 13:23 To: Dudziak Krzysztof ; Yocto-mailing-list Subject: Re: [yocto] inheriting native.bbclass explicitly CCing the list again. Please remember to reply to the list. On 13 September 2018 at 11:42, Dudziak Krzysztof wrote: > Is it possible for one Bitbake target to check list and order of classes > inherited? bitbake -e [recipe] will show you what was parsed. In this situation I wouldn't worry too much. It's best to use BBCLASSEXTEND instead of inherit native directly anyway. Ross This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building, Using SDK
Hi, Alex González elaborates in his book Embedded Linux Development Using Yocto Projets (2nd Edition) SDK-related questions - basics, building, usage (chapter 4). 1. Downloading then installing precompiled SDK was one of all available options according to Alex. He elaborates how to find it on server in Internet, how to select needed one and install it. I wonder how to integrate downloaded and installed precompiled SDK to Poky release used on build system? 2. Preparing / building SDK by oneself was further option with image target's 'populate_sdk' Bitbake task as the recommended way (according to Alex in chapter's certain section). One would need only to start populate_sdk task for image which matches root file system of system in development. As soon as task completed SDK can be installed using generated script. But how does it work for first build where rootfs was not built in the past. Is in that case following procedure the proper one? step 1: bitbake -c populate_sdk step 2: bitbake krzysiek This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] allarch class used in autoconf-archive recipe
Hi, myself grabbed autoconf-archive recipe from http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb to build and install autoconf archive for building user-space app. autoconf-archive package builds in Jethro, as the YP release used here is, without problems even if grabbed from release later than Jethro. That recipe inherits 'allarch' class. If to review Jethro Reference Manual following note can be found reg. 'allarch' class usage: "Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes that produce packages that depend on tunings through use of the RDEPENDS and TUNE_PKGARCH variables, should never be configured for all architectures using allarch. This is the case even if the recipes do not produce architecture-specific output. Configuring such recipes for all architectures causes the do_package_write_* tasks to have different signatures for the machines with different tunings. Additionally, unnecessary rebuilds occur every time an image for a different MACHINE is built even when the recipe never changes." Same note is to be found on reference manual's master branch. Few questions arise from that: 1. What might be best solution to the discrepancy "not recommended to use vs. used in OE-recipe"; to drop this inheritance? 2. How might recipe's past change-flow resulting in recipe's current version to inherit 'allarch' class look like? This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] inheriting native.bbclass explicitly
Got it and will follow your recommendation. Thanks. -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Thursday, 13. September 2018 14:00 To: Dudziak Krzysztof Cc: yocto@yoctoproject.org Subject: Re: [yocto] inheriting native.bbclass explicitly On 13 September 2018 at 12:39, Dudziak Krzysztof wrote: > Thanks for hints. > I don't want to have this package on target system. > You sound like inheriting explicitly had some major drawback of wide scope. It won't be included in the image unless you add it to the image. Ross This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
