On Fri, Jul 8, 2022 at 3:03 PM Alexander Kanavin <[email protected]> wrote:
>
> 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.
I did think of one way in which the order matters: If you are planning
on populating BBLAYERS from this list, the order would matter. If you
are doing that (or we want to allow it at all) it would need to be a
list instead of a dictionary.
>
> > > +++ 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.
Yep sorry.
>
> > > + "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.
Configuring _what_ you want to build is probably even more contentious
that describing how to fetch your layers, so for starters I'd really
like to just focus on the layer fetching; TEMPLATECONF is far from the
only method for doing build configuration and I don't think we should
bake it into the "layer setup" piece at this point (same for machine &
distro, although they aren't generally contentious, see below).
>
> > > + "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.
I suspect that not including the machine/distro/template stuff for now
might give us better adoption as standard way to describe layers,
which is another reason I'm a little hesitant to include them (in
addition to duplicating information available in the layer itself)
>
> Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167875):
https://lists.openembedded.org/g/openembedded-core/message/167875
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]]
-=-=-=-=-=-=-=-=-=-=-=-
