> I do not like bits and pieces of code scattered all over the place and gathered together by bitbake, that does not help readability.
My experience is opposite, developers tend to copy whole recipes without explaining why it was copied and what's the important diff they needed compared to upstream recipes (or .inc file). It's difficult to untangle when someone few years ago copied newer version of foo from warrior to thud based build in product repo, then someone else from different team cherry-picks "Add that feature" commit to dunfell based build (and now foo is downgraded from version in dunfell to the old version from warrior and the cherry-picked commit doesn't say why this version was duplicated). Then when I'm upgrading from dunfell to kirkstone it's really late to try finding the original warrior commit from which it was copied to see if there were some intentional changes in packaging during the "duplication". e.g. duplication in https://github.com/shr-project/meta-webosose/commit/1d61ee9739d61c061256077b231eb3fceed68f04 replaced with shorter bbappend in https://github.com/shr-project/meta-webosose/commit/d333fec00fb0bc57d38375ddcda269780837ce79 Yes developers should write better commit messages and provide useful comments in imported files, but at least in my experience very few do that and duplicating more hurts readability, for everything else there is bitbake -e to see where and how bitbake gathered the pieces. Having short .bbappend helps them to do only necessary changes. Changing the version in .bbappend is usually bad (especially when the original _ 1.0.bb recipe is versioned and the _1.0.bbappend sets PV = "2.0"), so reusing as much as possible from .inc file if it exists is the next best thing to keep the "diff" short. .bbappends also stop working from time to time when the upstream recipe changes, reusing .inc files isn't very different from that. Cheers, On Tue, Nov 1, 2022 at 10:11 AM Alexander Kanavin <[email protected]> wrote: > On Tue, 1 Nov 2022 at 09:12, Peter Bergin <[email protected]> wrote: > > This opened my eyes for the way systemd recipes are built up in oe-core. > > It seems a bit the other way around. systemd.inc contains almost only > > version information. systemd_251.4.bb is huge and contains a lot of > > thing that I think can be shared among versions. If it had been the > > other way around it had been easy to have a systemd_git.bb, including > > systemd.inc, in my local layer (or upstream if desired) that build > > systemd main branch. What do you think of that? Is is worth working on > > such a patch? Or are there reasons for that setup? > > I prefer the opposite actually. Where possible, I fold the .inc files > into the main recipe because that makes maintenance easier, and if > someone needs to change that in non-upstreamable manner, they have to > perform a full fork in a private layer. I do not like bits and pieces > of code scattered all over the place and gathered together by bitbake, > that does not help readability. > > For systemd, I think the reason for systemd.inc is that something else > in the same folder is using it. > > Alex > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#172355): https://lists.openembedded.org/g/openembedded-core/message/172355 Mute This Topic: https://lists.openembedded.org/mt/94696056/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
