On Fri, 8 Jul 2022 at 21:33, Joshua Watt <[email protected]> wrote:
> > -- all lists (sources, layers, remotes) are replaced by objects keyed by
> > 'name' properties of the list items.
> > This allows using them as dicts inside Python, and makes the json more
> > compact and readable.
>
> As long as the order is truly irrelevant because different
> implementations (and even different versions of Python!) will result
> in a different processing order.
Yes, for all of those things it's irrelevant.
> > +++ b/meta/files/layers.example.json
> > @@ -0,0 +1,115 @@
> > +{
>
> Missing the version? Although I see it's in the schema.
It's at the end of the file. File is written via python's json module
which decides where it goes.
> > + "sources": {
> > + "meta-alex": {
> > + "contains_this_file": true,
> > + "git-remote": {
>
> The problem with this is that there has been some desire for other
> fetching mechanisms; Perhaps we can say git is only supported, but
> that was the reason I used `oneOf`: it allows for other fetching types
> in the future.
'git-remote' is not a mandatory property in the json, it can be
absent, and instead there can be 'svn-remote', 'tarball' or
'delivered-by-doves'. Anything you want. Just propose an object
definition into the schema.
>
> > + "branch": "master",
> > + "describe": "",
> > + "remotes": {
> > + "remote-alex": {
> > + "uri": "https://github.com/kanavin/meta-alex";
> > + }
>
> Multiple remotes are nice.... but not strictly necessary, since you
> can only have one rev checked out. I don't care too much one way or
> another but it's something to think about since it makes the fetching
> more complicated.
It isn't at all more complicated to handle multiple remotes in the
fetch script which I suggest you look at and try out. I don't want to
have to guess which of the remotes is the right one either when
writing the json, or when using it: I'm writing them all, and fetching
from all as well, ignoring the failures (the failure only happens if
needed revision is absent and can't be checked out). You can write and
check out single remotes if you so wish, but then you have to decide
how to choose out of several.
>
> > + },
> > + "rev": "05b25605fb8b2399e4706d7323828676bf0da0b5"
> > + },
> > + "layers": {
> > + "meta-alex": {
> > + "buildconfigs": {
> > + "conf/templates/configuration-gadget": {},
> > + "conf/templates/configuration-gizmo": {}
>
> I think these fall under the same category as the machines below, but
> I don't use TEMPLATECONF so I'm not sure.
They're not quite same as machines or distros, as they can be anywhere
in the layer. This saves you the trouble of walking over the layer
tree, especially when look at the layer repo through the browser.
> > + "meta-intel": {
> > + "machines": {
> > + "intel-core2-32": {},
> > + "intel-corei7-64": {},
> > + "intel-skylake-64": {}
>
> Why does this need to be listed here? Isn't this just the contents of
> the conf/machine directory in the layer? I really don't want to be
> duplicating information; IHMO it's better to let the layer itself be
> canonical about what machines/distros/etc. it supports
Then you would have to check out all the layers first and look at them
one by one. The idea is that this information is available upfront,
and for all of the layers in a build. It can be used, for example to
be used by Richard's proposed oe-setup tool, and as the json is never
written or edited manually, it won't get out of sync wrt git revision
it lists for the layer.
The plain list of machines isn't that interesting, but if it comes
with additional information such as descriptions, architectures or
kernel versions etc., then it's quite useful to capture this in a
standard format. We could maybe look at how buildroot handles this.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167833):
https://lists.openembedded.org/g/openembedded-core/message/167833
Mute This Topic: https://lists.openembedded.org/mt/92259024/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
