> -----Original Message----- > From: openembedded-core@lists.openembedded.org <openembedded- > c...@lists.openembedded.org> On Behalf Of Alexander Kanavin > Sent: den 14 september 2022 09:42 > To: ChenQi <qi.c...@windriver.com> > Cc: OE-core <openembedded-core@lists.openembedded.org>; Alexander Kanavin > <a...@linutronix.de> > Subject: Re: [OE-core] [PATCH 1/7] scripts/oe-setup-builddir: add a check > that TEMPLATECONF is valid > > On Wed, 14 Sept 2022 at 10:17, ChenQi <qi.c...@windriver.com> wrote: > > The codes are in: https://github.com/WindRiver-Labs/wrlinux-x > > > > e.g. > > > > ./wrlinux-x/setup.sh --all-layers (this pulls down all supported layers) > > > > ./wrlinux-x/setup.sh --all-layers --dl-layers (this pulls down all > > supported layers, together with their needed tarballs/git repos) > > > > ./wrlinux-x/setup.sh (this pulls down the default list of layers) > > > > ./wrlinux-x/setup.sh --layers meta-xxx (this pulls down the default list > > of layers + meta-xxx and its dependencies) > > > > And the final list of layers are in > > <project_dir>/config/bblayers.conf.sample, which will be updated if > > needed when re-running the setup.sh script. > > May I suggest that the tool skips the bblayers.conf.sample step > altogether, and simply writes the desired layers directly into > bblayers.conf? It can do this with 'bitbake-layers add-layer'. Is > there a need for doing the intermediate step of generating the > template?
I know you have suggested this to me too as we use a similar setup to generate the bblayers.conf.sample file based on the layers that repo has checked out in our environment, and now I realized why this is not as simple as it seems. The problem (at least in our case) is that we run as a wrapper around oe-init-build-env. This means that before the wrapper sources oe-init-build-env, the build directory and thus the conf directory inside it (where the bblayers.conf file is supposed to go) may not exist. And after it has sourced oe-init-build-env it is too late as the bblayers.conf file needs to exists before. So to create the bblayers.conf file, the wrapper would have to duplicate all the non-trivial code in oe-setup-builddir that determines what the build directory should be called. And while this of course is possible to do, it means duplicating code that is internal to bitbake, and risking missing important changes to the upstream code in the future. Thus it is much easier and safer to generate the template files and let oe-init-build-env do its job. > > Just to be clear where I am coming from: anything in TEMPLATECONF must > not be auto-generated during build setup, and must be under version > control. We are trying to standardize layer setup and configuration > handling, and this would be a necessary step towards that. Where I (and apparently WindRiver) are coming from, the decision on what layers are part of the configuration is not something a specific layer is responsible for. I.e., in our setup we fetch the layers we want for a build, write the list of layers to bblayers.conf.sample and source oe-init-build-env. With your setup, if I want a project with the two layers meta-a and meta-b, I would also have to create a layer meta-x where I create a static bblayers.conf.sample file that lists these three layers. Then, if another project wants to use meta-a and meta-c, they would have to add a second static bblayers.conf.sample file in meta-x that lists those three layers. Basically every time there is a new combination of layers fetched, there would also have to be a duplicate of the information in a static bblayers.conf.sample file somewhere. I am probably missing something here, but to me this seems suboptimal. If the list of layers in the static file had been used to fetch the layers, I would better understand it, but then the problem becomes that the list is now in one of the arbitrary layers that are supposed to be fetched. For reference, today when one of our teams start a new development project, what they do is they create a specific layer (e.g., meta-foo) for that project where they can do all their development work and experimentation until it is time for them to integrate to our main platform (referred to as cfp/cfp.xml below). Then they create a repo manifest that looks like: <?xml version="1.0" encoding="UTF-8"?> <manifest> <include name="cfp/cfp.xml"/> <project path="meta-foo" name="layers/projects/meta-foo" revision="master"/> </manifest> in our manifest repository. This simple manifest is all the project team needs to create to build with their project specific layer. It also means that the only input to our Jenkins jobs to build for this project (instead of the main platform) is the name of the project's repo manifest. It also means that if we make any changes to the main platform, e.g., add a new layer (which is a one line change to the cfp.xml manifest), all projects will automatically get and use that new layer without having to make any changes to all the project manifests. > > Alex //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170677): https://lists.openembedded.org/g/openembedded-core/message/170677 Mute This Topic: https://lists.openembedded.org/mt/93368468/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
