Ok, I tried it again, and it didn't work for me (or at least, didn't do what I would have liked). You can set MACHINE and DISTRO in config fragments, *but* it doesn't affect the machine or distro include in bitbake.conf. This means you can't really specify MACHINE or DISTRO in a fragment, or you're likely to get really strange results. You can see this pretty easily in the environment output; the MACHINE variable proper may be set to whatever is in the fragment, but the included machine file is not the one that is specified and thus the actual machine settings will be really weird (same for DISTRO).
I won't claim to speak for everyone who wants config fragments, but in my experience, this means that these config fragments aren unlikely to be able to replace many of the existing tooling that does configuration (e.g. whisk, kas, et. al). As the number of developers working on project grows, and you try to build more and more builds/projects/products (hereafter just called "products") out of the same repo, it gets increasing difficult to expect users to manage switching between different products by changing environment variables and/or local.conf settings. What the existing configuration management tools have going for them is that they make this very easy; it's just a single pretty easy to understand system that allows an end user to exactly replicate the product "as intended" (e.g. you can precisely replicate the configuration that all other users are using). In the case of whisk specifically, it's designed such that everything the user needs to replicate the build is specified by whisk, and local.conf only needs to have anything in it if they want to change something for their local build. This has worked extremely well for us in our use cases, as it's well understood that if you are having problems, the first step is to see what changes you've made in local.conf and/or remove them to see if the problem can still be replicated. https://github.com/JPEWdev/oe-doom-demo works in a very similar vein, except it does so without using whisk. The idea is that the user can set a single environment variable (BUILD_DEVICE) and precisely replicate the intended build. I would love to be able to do this with config fragements instead, as like pretty much all the other features of them, but if I can't set MACHINE and DISTRO, it doesn't really feel worth it (IMHO). On Wed, Dec 25, 2024 at 8:33 AM Joshua Watt <[email protected]> wrote: > > Hmm, ok, I'll try again. > > On Wed, Dec 25, 2024, 8:29 AM Alexander Kanavin <[email protected]> > wrote: >> >> On Fri, 20 Dec 2024 at 18:39, Joshua Watt <[email protected]> wrote: >> > 1) bitbake-config-build is way too aggressive in the files it looks >> > for as fragments. My editor (vim) creates hidden temporary files that >> > I kept having to manually delete or the tool would attempt to parse >> > them and fail. I would recommend that it only consider non-hidden >> > files that end in .conf as valid fragments. >> > 2) It would be convenient if `bitbake-config-build enable-fragment` >> > and `bitbake-config-build disable-fragment` could take more than one >> > fragment, as this would make scripting in CI more straight forward. >> >> I see the patches for these have been sent, thanks. >> >> > 3) The biggest problem I had with this is that I can't set variables >> > like MACHINE/DISTRO etc. in fragments, I think this is due to how >> > deferred the evaluation of this is. Without being able to do this, I'm >> > not sure how useful this system will be for me (or at least, it won't >> > be able to replace any of the current mechanisms I use). I think what >> > users are generally after here is that they can really easily share a >> > configuration in source control (which this does well), but if it >> > can't control everything it's of limited use. >> >> I tried this locally with poky and adding DISTRO/MACHINE to one of the >> selftest fragments, and it works properly, so if you can provide a way >> to reproduce this problem I'd appreciate. Or there's something else on >> your side that gets in the way. >> >> Here's the output of bitbake -e (DISTRO is similarly adjusted as expected): >> >> # >> # $MACHINE [3 operations] >> # set /srv/storage/alex/yocto/build-64/conf/local.conf:38 >> # [_defaultval] "qemux86-64" >> # set /srv/work/alex/poky/meta/conf/documentation.conf:279 >> # [doc] "Specifies the target device for which the image is built. >> You define MACHINE in the conf/local.conf file in the Build >> Directory." >> # set /srv/work/alex/poky/meta-selftest/conf/fragments/test-fragment.conf:5 >> # "qemuarm" >> # pre-expansion value: >> # "qemuarm" >> MACHINE="qemuarm" >> >> Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#209105): https://lists.openembedded.org/g/openembedded-core/message/209105 Mute This Topic: https://lists.openembedded.org/mt/109647318/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
