On Wed, 14 Jan 2026 at 18:43, Daiane Angolini
<[email protected]> wrote:
> Let me frase this in another way. My project has all and every
> configuration needed into a distro conf file. I want to create a
> .conf.json to share. Can I create one file without any
> variant/fragment/bitbake configuration?
You still need to specify in the json what layers need to be included
into a bitbake configuration, and what distro and what machine needs
to be selected, if you want bitbake-setup to produce a functional
build where bitbake can run. If you don't do that, bitbake will
immediately tell that a machine isn't set, or that there are no layers
or some such error.
So you need to define at least one top level variant thusly:
"bitbake-setup": {
"configurations": [
{
"name": "poky how it used to be"
"bb-layers":
["openembedded-core/meta","meta-yocto/meta-yocto-bsp","meta-yocto/meta-poky"],
"oe-fragments": ["machine/qemux86-64", "distro/poky"]
}
]
}
In another message there's a question of what would be the equivalent of:
git clone <poky> -b LTS
source oe-init-build-env
bitbake <image>
The above is the equivalent. bitbake-setup will not ask any questions
about choosing something, because there is only one choice.
I appreciate the standard configs are quite a bit more complex than
that, and a 'simple' example might've been helpful, but we want to
give users a range of options rather than impose very specific
selections on them as was done previously.
> Or, Why is the variant "poky" empty? [1]
There's a "poky-with-sstate" variant next to it. Both variants are
nested in a higher level variant that sets common configuration for
both of them. One is supposed to use that common configuration without
change, the other adds the sstate enabling fragment. Think of it as a
tree of variants. You can define sub-variants with as much nesting as
you want. For example if you have a range of target machines, they
could all share a common configuration, and then each would add a
specific machine fragment.
> Or, why is there "two pokys" for me to choose?
>
> ```
> Available configurations:
> 1. poky-master Poky - The Yocto Project testing distribution
> configurations and hardware test platforms
>
> Available bitbake configurations:
> 1. poky Poky - The Yocto Project testing distribution
> ```
> from the iterative `bitbake-setup init` output, from [2]
Please do not trim the output because that gives a misleading
impression that the same question is being asked.
The first question is about whether you want poky (the reference
testing distro) or a basic openembedded build, and which release of
either (master, or whinlatter, or soon there will be the upcoming LTS
option there as well) you prefer:
Available configurations:
1. oe-nodistro-master OpenEmbedded - 'nodistro' basic configuration
2. oe-nodistro-whinlatter OpenEmbedded - 'nodistro' basic
configuration, release 5.3 'whinlatter' (supported until 2026-05-31)
3. poky-master Poky - The Yocto Project testing distribution
configurations and hardware test platforms
4. poky-whinlatter Poky - The Yocto Project testing distribution
configurations and hardware test platforms, release 5.3 'whinlatter'
(supported until 2026-05-31)
Assuming you chose poky, he second question is about whether you want
to enable pre-build sstate from yocto infrastructure to accelerate
your builds if your machine isn't very powerful:
Available bitbake configurations:
1. poky Poky - The Yocto Project testing distribution
2. poky-with-sstate Poky - The Yocto Project testing distribution
with internet sstate acceleration. Use with caution as it requires a
completely robust local network with sufficient bandwidth.
We could probably improve the descriptions and suggestions in these,
but the intents of these choices are hopefully more clear now.
> And when I created the draft `conf.json` for meta-freescale I realized
> I could just choose none of the variants (because the base is the
> DISTRO and I might want only that)
You still need to create one top level variant with that distro name
specified in it, and the list of layers to enable, and perhaps a
target machine.
> I'm not sure it makes sense, please help me understand
Hopefully this is a bit more clear now.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229390):
https://lists.openembedded.org/g/openembedded-core/message/229390
Mute This Topic: https://lists.openembedded.org/mt/117264857/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
