[OE-core] How to set up custom layer correctly

[Andrey Zhizhikin]

Hey Ankur,

On Wed, Nov 13, 2019 at 9:55 PM Ankur Tyagi <ankur.tyagi85 at gmail.com> wrote:
>
> Hi,
>
> I have a custom layer for custom board based upon am335x-evm and custom images.
>
> I have a master layer called "my-custom-layer" which has three sub-layers
> - my-custom-distro : custom distro based upon TI's 'arago' distro, Qt
> and other s/w recipe appends
> - my-custom-image : custom images, packagegroups, toolchain recipes
> - my-custom-machine : custom machine conf, bsp and kernel recipes

Those config files are OK to create, but can you please tell how did
you create your own machine?

>
> When I am building my image, it throws numerous warnings like below
> for almost all packages in the image:
>
> eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: libudev rdepends on
> u-boot-custom-src, but it isn't a build dependency, missing
> u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps]
> WARNING: eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: eudev
> rdepends on u-boot-custom-src, but it isn't a build dependency,
> missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps]
> WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput rdepends
> on u-boot-custom-src, but it isn't a build dependency, missing
> u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps]
> WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput-bin
> rdepends on u-boot-custom-src, but it isn't a build dependency,
> missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps]
>

I would be interesting to see your u-boot-custom recipe here. Looks
like this one is not formed well enough. Did you base it from u-boot
recipe of am335x layer?

Another thing is if you're building your own version of U-Boot - you
would need to set a PREFERRED_PROVIDER to point to it. This

>
> And once sstate-cache is built and if I try to reuse it after bumping
> u-boot-custom to new SRCREV then I get errors like:
>
> Collected errors:
>  * Solver encountered 2 problem(s):
>  * Problem 1/2:
>  *   - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606
> needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl
>  *
>  * Solution 1:
>  *   - do not ask to install a package providing packagegroup-ggl-base
>
>  * Problem 2/2:
>  *   - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606
> needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl
>  *
>  * Solution 1:
>  *   - do not ask to install a package providing packagegroup-ggl-qt
>
Those might come from the point I stated above - your u-boot recipe
does not provide necessary packages, or the PREFERRED_PROVIDER might
not be set correctly.

> Something is definitely not right the way I am have setup my layers
> but I would like to understand what is wrong, why it is wrong and what
> is the recommended way to do it

I can tell you how I personally do it. This is a mere experience that
I have and it does not serve as an official How-To - there is a very
good documentation about the process of using Yocto on the website. :)
I base my new configuration on the oe-core/vendor BSP, utilizing as
much as possible from it at the first step. Then once the evaluation
image is built (for example core-image-minimal) I examine the
distro/machine to identify whether I can use it as-is, or create my
distro/machine based on those provided. In later case I try to keep it
as close to original source as possible, this would allow ease of
upgrade in the future.

As a suggested reading here:
https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html

> Because in future I would like to add different machines, distros and
> images for different custom products. That is why instead of putting
> everything inside one layer I thought of keeping a separate layer for
> each.

This is a correct approach to follow. The only thing you would always
have to keep in mind is a concept of "non-destructive layer", meaning
that if you remove your layer from the build system - it should not
affect all other layers you have included, and you should always have
a possibility to build other distro/machine/image triplets. In other
words - don't pollute your build system with unnecessary dependencies.

>
> Looking forward to learning from your responses.
>
> Thanks
> Ankur
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Regards,
Andrey.