On 2017-08-14 3:36 PM, Gunnar Andersson wrote:

Yocto community,

Triggered by the previous email request to yocto@ about best practices for
layer organization I'm finally firing off this email for (hopefully) some
feedback on an idea we first kicked around, discussed for rough consensus
and then decided to implement in the Yocto based GDP project [1].  You can
see it as a trial, anything can be changed, but so far so good...

We adopted a somewhat novel (but actually not really unique, see inside)
naming convention [2] for all modifications to components that belong to
other layers.


I've been using a similar naming/sorting mechanism in layers that
I maintain for several years now. When you have a single layer that
is carrying bbappends to many other layers, I find that it really
helps keep everything separated and aids finding the original
recipe.

(that being said, recent work with layer index, etc, make it
easier to locate the original recipe and any bbappends .. but that
doesn't preclude keeping things organized in a layer).

Cheers,

Bruce

This convention shows what layers are being modified by the .bbappends by
actually naming the layer it is (intending to**) modify.  The initiative
also aims to highlight and separate .bbappends (modifications) from uniquely
added components in our project (new .bb files) in GDP.

**Note that we are well aware this does NOT control bitbake behavior (as
neither does the recipe-xxx/ directory convention), and is therefore just a
guide.  If the project is misconfigured, bitbake could do something
different than the naming convention implies and it could even be
misleading, but at least the *programmer intent* is shown clearly.

I think it also makes .bbappends more explicitly visible and might trigger
the idea:   Do we really need this?  Are we really modifying *that* adopted
layer, and if so, why?

To Russel who wrote the previous request for guidance - feel free to
consider, but I won't recommend this directly since it's by no means an
agreed best practice in all of the community.  I'm rather asking for other
experienced OE developers to consider and comment on the idea.

For oldtimers it's probably easy to find this odd and just be negative
against it since well, "standard practice", inertia, NIH and all that, but
I'll stick my neck out anyway because it seems to solve some issues of
organization and understanding at least for us (and I'm a sucker for some
flamebait ;)

If the intro is too formal and long, just look at the final examples.  I
think you'll get it.  Feel free to ask.


- Gunnar

--
Gunnar Andersson <ganders...@genivi.org>
Development Lead
GENIVI Alliance

[1] https://github.com/GENIVI/genivi-dev-platform
[2] Naming strategy for bitbake extension layers:                       
https://at.projects.genivi.org/wiki/x/w4Xk




--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to