On Fri, Jul 8, 2022 at 2:17 PM Alexander Kanavin <[email protected]> wrote: > > From: Joshua Watt <[email protected]> > > Defines a common schema for layer setup that can be consumed by tools to > know how to fetch and assemble layers for end users. Also includes an > example of the layer setup that constructs poky/meta-intel/imaginary product > layer > for reference. > > The schema can be used to validate a layer setup file with the commands: > > $ python3 -m pip install jsonschema > $ jsonschema -i meta/files/layers.example.json meta/files/layers.schema.json > > Signed-off-by: Joshua Watt <[email protected]> > > Alex: I made the following modifications to Joshua's original commit: > > - moved the files from meta/lib to meta/files > > - the example json showcases a multi-repo, multi-layer setup with additional > configurations and machines, instead of just poky - closer to a typical > product > > - the schema is modified so that: > > -- 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. > > -- added 'contains_this_file' property to source object > > -- added 'buildconfigs', 'machines' and 'distros' properties to layer objects. > > -- replaced 'remote' property with a 'oneOf' definition for git with a > specific > 'git-remote' property. 'oneOf' is problematic when schema validation fails: > the diagnostic is only that none of oneOf variants matched, which is too > non-specific. > > -- added 'describe' property to 'git-remote' object. > > FIXME: > - oe-selftest that validates the example json against the schema using > python3-jsonschema-native > > Signed-off-by: Alexander Kanavin <[email protected]> > --- > meta/files/layers.example.json | 115 ++++++++++++++++++++++++++++++ > meta/files/layers.schema.json | 125 +++++++++++++++++++++++++++++++++ > 2 files changed, 240 insertions(+) > create mode 100644 meta/files/layers.example.json > create mode 100644 meta/files/layers.schema.json > > diff --git a/meta/files/layers.example.json b/meta/files/layers.example.json > new file mode 100644 > index 0000000000..f606567b9d > --- /dev/null > +++ b/meta/files/layers.example.json > @@ -0,0 +1,115 @@ > +{ Missing the version? Although I see it's in the schema. > + "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. > + "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. > + }, > + "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. > + }, > + "subpath": "" > + } > + }, > + "path": "meta-alex" > + }, > + "meta-intel": { > + "git-remote": { > + "branch": "master", > + "describe": "15.0-hardknott-3.3-310-g0a96edae", > + "remotes": { > + "origin": { > + "uri": "git://git.yoctoproject.org/meta-intel" > + } > + }, > + "rev": "0a96edae609a3f48befac36af82cf1eed6786b4a" > + }, > + "layers": { > + "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 > + }, > + "subpath": "" > + } > + }, > + "path": "meta-intel" > + }, > + "poky": { > + "git-remote": { > + "branch": "akanavin/setup-layers", > + "describe": "4.1_M1-374-g9dda719b2a", > + "remotes": { > + "origin": { > + "uri": "git://git.yoctoproject.org/poky" > + }, > + "poky-contrib": { > + "uri": > "ssh://[email protected]/poky-contrib" > + } > + }, > + "rev": "9dda719b2a4727a4d43a6ab8d9e23f8ca68790ec" > + }, > + "layers": { > + "meta": { > + "distros": { > + "defaultsetup": {} Same as machines above > + }, > + "machines": { > + "qemuarm": {}, > + "qemuarm64": {}, > + "qemuarmv5": {}, > + "qemumips": {}, > + "qemumips64": {}, > + "qemuppc": {}, > + "qemuppc64": {}, > + "qemuriscv32": {}, > + "qemuriscv64": {}, > + "qemux86": {}, > + "qemux86-64": {} > + }, > + "subpath": "meta" > + }, > + "meta-poky": { > + "buildconfigs": { > + "conf": {} > + }, > + "distros": { > + "poky": {}, > + "poky-altcfg": {}, > + "poky-bleeding": {}, > + "poky-tiny": {} > + }, > + "subpath": "meta-poky" > + }, > + "meta-selftest": { > + "machines": { > + "qemux86copy": {} > + }, > + "subpath": "meta-selftest" > + }, > + "meta-yocto-bsp": { > + "machines": { > + "beaglebone-yocto": {}, > + "edgerouter": {}, > + "genericx86": {}, > + "genericx86-64": {} > + }, > + "subpath": "meta-yocto-bsp" > + } > + }, > + "path": "poky" > + } > + }, > + "version": "1.0" > +} > \ No newline at end of file > diff --git a/meta/files/layers.schema.json b/meta/files/layers.schema.json > new file mode 100644 > index 0000000000..ba46e00b52 > --- /dev/null > +++ b/meta/files/layers.schema.json > @@ -0,0 +1,125 @@ > +{ > + "description": "OpenEmbedder Layer Setup Manifest", > + "type": "object", > + "additionalProperties": false, > + "required": [ > + "version" > + ], > + "properties": { > + "version": { > + "description": "The version of this document; currently '1.0'", > + "enum": ["1.0"] > + }, > + "sources": { > + "description": "The dict of layer sources", > + "type": "object", > + "patternProperties": { ".*" : { > + "type": "object", > + "description": "The upstream source from which a set of > layers may be fetched", > + "additionalProperties": false, > + "required": [ > + "path" > + ], > + "properties": { > + "path": { > + "description": "The path where this layer source > will be placed when fetching", > + "type": "string" > + }, > + "description": { > + "description": "A description of this layer source", > + "type": "string" > + }, > + "contains_this_file": { > + "description": "Whether the directory with the layer > source also contains this json description. Tools may want to skip the > checkout of the source then.", > + "type": "boolean" > + }, > + "layers": { > + "description": "The dict of layers to be used from > this upstream source", > + "type": "object", > + "patternProperties": { ".*" : { > + "description": "A layer from the upstream > source", > + "type": "object", > + "additionalProperties": false, > + "properties": { > + "subpath": { > + "description": "The subpath (relative to > the source root) for this layer. Omit if the source root is the layer path", > + "type": "string" > + }, > + "buildconfigs": { > + "description": "A dict of template build > configurations in the layer, keyed by relative path to the layer root", > + "type": "object", > + "patternProperties": { ".*" : { > + "description": "Properties of a > build confuguration template", > + "type": "object", > + "additionalProperties": false, > + "properties":{} > + }} > + }, > + "machines": { > + "description": "A dict of machine > definitions in the layer", > + "type": "object", > + "patternProperties": { ".*" : { > + "description": "Properties of a > machine definition", > + "type": "object", > + "additionalProperties": false, > + "properties":{} > + }} > + }, > + "distros": { > + "description": "A dict of distro > definitions in the layer", > + "type": "object", > + "patternProperties": { ".*" : { > + "description": "Properties of a > distro definition", > + "type": "object", > + "additionalProperties": false, > + "properties":{} > + }} > + } > + } > + }} > + }, > + "git-remote": { > + "description": "A remote git source from > which to fetch", > + "type": "object", > + "additionalProperties": false, > + "required": [ > + "rev" > + ], > + "properties": { > + "branch": { > + "description": "The git branch to > fetch (optional)", > + "type": "string" > + }, > + "rev": { > + "description": "The git revision to > checkout", > + "type": "string" > + }, > + "describe": { > + "description": "The output of 'git > describe' (human readable description of the revision using tags in revision > history).", > + "type": "string" > + }, > + "remotes": { > + "description": "The dict of git > remotes to add to this repository", > + "type": "object", > + "patternProperties": { ".*" : { > + "description": "A git remote", > + "type": "object", > + "addtionalProperties": false, > + "required": [ > + "uri" > + ], > + "properties": { > + "uri": { > + "description": "The URI > for the remote", > + "type": "string" > + } > + } > + }} > + } > + } > + } > + } > + } > + }} > + } > +} > -- > 2.30.2 >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167832): https://lists.openembedded.org/g/openembedded-core/message/167832 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]] -=-=-=-=-=-=-=-=-=-=-=-
