On Mon, 2024-06-10 at 12:58 +0200, Alexander Kanavin wrote:
> On Mon, 10 Jun 2024 at 12:08, Richard Purdie
> <[email protected]> wrote:
>
> > b) The code adding/removing require lines from local.conf seems a
> > little fragile. I did wonder if we wanted a higher level bitbake
> > API to
> > this, for example a BB_CONF_FRAGMENTS variable which basically
> > tagges a
> > set of config files onto the end of the base configuration parsing?
> > This wouldn't be hard to implement in bitbake and would then make
> > the
> > tooling easier and less fragile.
>
> I don't quite follow. If BB_CONF_FRAGMENTS value is a space separated
> list of fragments, then how would the tooling
>
> - add to it?
> - remove from it?
bb.utils.edit_metadata()/bb.utils.edit_metadata_file() ?
> It would still need to look for an assignment to that variable in a
> 'standard location' (e.g. conf/local.conf), and then rewrite the file
> with the new assignment. That doesn't seem any easier to me than just
> using 'require path/to/fragment'.
I can see this both ways but we do have the helper functions above that
can do this (as used in recipetool/devtool).
> On the other hand, there could be qa checks for presence of a certain
> fragment(s) in that variable. E.g. a layer could stop a build if it
> detects that something is not there.
I'm wondering about whether having a variable makes it easier to users
to understand/edit.
I meant to also mention that I'm a bit concerned about using local.conf
specifically in the tool, I'd prefer not to require a specific conf
file.
> Another option is to copy/symlink the fragments into
> build/conf/fragments/ and have bitbake pick them up with a glob.
I don't like the copy idea, the symlink approach is interesting. The
main downside there is capturing the give config and ordering.
> > c) Do we want to have the config fragment name as a
> > "<layername>/<fragementname>" pair and have the fragments live
> > directly
> > in conf/fragments in a layer?
>
> The idea is to allow deep slash-separated hierarchies here to be used
> as categories, and map their names directly to file paths (stripping
> the conf/fragments/ prefix and .inc suffix in the tooling UI). Think
> of something like
> meta-yocto-bsp/conf/fragments/machines/arm/beaglebone.inc that would
> be presented as 'machines/arm/beaglebone' in the UI. Conversely, what
> layer it's in is not relevant in the tooling UI. If someone wants to
> enable systemd, they wouldn't care which layer would give them that.
That seems reasonable but I wanted to avoid every layer needing to nest
by a directory level to make it clear where the fragments come from. I
think some kind of naming standard might ultimately make things clearer
to the user?
Requiring the first entry be a layer name doesn't preclude the rest...
> This would come particularly handy in interactive UIs (e.g. something
> curses-driven and mimicking buildroot).
>
> > d) How do you control ordering between the fragments? Do we need
> > dependencies? How does layer ordering or dependencies affect
> > anything?
> > Can fragments conflict?
>
> I deliberately kept all of this out of scope to avoid going crazy
> with thought experiments and resulting over-engineering. I feel we
> need to start using the fragments in practice, particularly eat our
> own dog food on the autobuilder with them, and then problems and
> answers to them will arise from that practice.
I ask the questions since we have been trapped by choices in the past
and it since these are likely things which will arise, we might want to
at least consider them now.
> > e) You've used comments at the start of the files as
> > summary/description. Should we use some kind of more variable like
> > syntax which allows for other information in the future?
>
> I'm open to proposals, but this was by far the easiest and most
> straightforward and obvious to anyone reading the fragment. Python
> has no support for 'metadata in comments' that we can reuse. If
> there's need for other metadata about fragments we can invent special
> syntax for it, but summary/description pair can stay as #-comments.
We do have our parser which can easily handle:
CONFFRAG[summary] = "some summary"
CONFFRAG[description] = "Longer description with \
multiple \
lines \
"
or
CONFFRAGS += "myfragment_name"
myfragment_name[summary] = "some summary"
myfragment_name[description] = "Longer description with \
multiple \
lines \
"
both of which have some pros and cons. I'm not sold on either of the
above but I wanted to give some examples.
For examples on handling such files see lib/bb/tests/parse.py,
basically call bb.parse.handle(f.name, self.d)[''].
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200475):
https://lists.openembedded.org/g/openembedded-core/message/200475
Mute This Topic: https://lists.openembedded.org/mt/106004166/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
