-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bblayers order #36
Comments
BTW: I removed |
kas processes repos in parallel, plus repos and layers can come different include files. This made generated config files undeterministic, see c9326cc. I'm open for a more user-controllable ordering algorithm, provided it's deterministic. But it's not a simple thing to solve I'm afraid. Weren't layer prior invented for sorting out such ordering issues? |
I'm not entirely sure and probably lack deeper understanding of how things are put together under the hood. I always thought that layer order actually matters. Given that two layers have identical priorities wouldn't assignments with e.g. I asked in the yocto irc if order matters and basically got two replies:
If order matters, c9326cc would be rather counterproductive. |
That commit was needed as we were otherwise producing even random orders. But things seem to have changed since then, including
We may still have an undesired order of things across includes, simply because ordering was so far not checked. If that's the case, I suppose we can sort that out before the next release if folks with such workload provide feedback (our layering does not rely on ordering, thus cannot help). |
According to c9326cc, we had issues with producing a deterministic order for those config elements. As sorting is a rather blunt method of resolving it and as ordering plays a role in bitbake's processing of the configs, we should try harder to provide more user control over that. A key role in this play ordered dictionaries that report their content the same order it was added. We already use OrderedDict for merging the config dict across includes, see _internal_dict_merge. Includes are merged recursively, depths-first, thus are expected to be deterministic and predictable. We just need to convert building the repo_dict to OrderedDict, and them sorted() can be removed. Closes: #36 Reported-by: Marius Kriegerowski <marius.kriegerowski@gfz-potsdam.de> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Hey, sorry for the late reply. I did a quick test and can confirm that that patch preserves the layer order! |
Let me know if I can help with anything else on that end. |
According to c9326cc, we had issues with producing a deterministic order for those config elements. As sorting is a rather blunt method of resolving it and as ordering plays a role in bitbake's processing of the configs, we should try harder to provide more user control over that. A key role in this play ordered dictionaries that report their content the same order it was added. With Python 3.6 now the minimal supported version, this is the default behavior. So it's safe to remove sorted(). Closes: #36 Reported-by: Marius Kriegerowski <marius.kriegerowski@gfz-potsdam.de> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Sorting by list order was discussed in https://groups.google.com/g/kas-devel/c/kbX_NAtQEMk, and we concluded to stick with ordering by name. |
@jan-kiszka |
Ordering is by layer key, as defined in the kas files. Is that external delivery providing you kas files as well? But even then: There is always a way to move a string before or after an existing set of stings. |
Can you please explain what do you mean by layer key?
ends up creating bblayers.conf:
So repo names get sorted, which is not what I would expect. What do you mean by layer key? |
Please read the email thread referenced in this issue, specifically https://groups.google.com/g/kas-devel/c/kbX_NAtQEMk/m/jYQzuz5VAgAJ. |
Sorry for resurrecting the dead. I've just stumbled upon a similar problem and wanted to add some thoughts on this. From how I read this issue,
Note in the above, that the docs explicitly refer to recipes and append files.
and
So to my understanding, In my specific use case, it was enough to employ the workaround referenced above. But I feel like this only works if there is a one-to-one mapping between git-repositories and layers. As soon as one maintains several layers within the same git repository,1 there is no way for the user to fully control the layers' ordering in Footnotes
|
Hey,
the order of layers in BBLAYERS in the generated build directory deviates from the order in my yml configuration.
After removing
bblayers.conf
(just to see that I'm not mistaken) I runkas build mconfig.yml
. This is BBLAYERS:And this is the order of my yml file:
As you can see it's not reversed but just different. The actual config includes another config.yml but that one doesn't define any layers or repos. Any idea why that happens?
The text was updated successfully, but these errors were encountered: