On Mon, 31 Jul 2023 at 12:56, Richard Purdie <[email protected]> wrote:
> I've just been looking at this again and I'm still not convinced this
> is right. In particular, the above output worries me a lot, partly as I
> barely understand it and I suspect if I struggle, I won't be the only
> one.
>
> With this kind of core tool, the "interface" to the user needs to be
> really clear and the problem here is that it isn't.
>
> Being more specific, from the above it is listing some commands I could
> run, but the user is being left to work out what the difference is for
> themselves. If I print a list like:
>
> a) poky default
> b) gizmo config
> c) gadget config
>
> then ask the user to select one, it is clear as the user is drawn to
> the key information. In the above text output, you have to know where
> to look in the commands to guess the pieces.
>
> The "/srv/work/alex" string is confusing the output and in many ways
> even filtering that out would help reduce the "superfluous" text but
> the issue does run deeper than that.
>
> As another example, perhaps I shouldn't need the -v to get at least
> some summary of what each one does?
Thanks, I'm glad this wasn't forgotten (or quietly shelved :). I kinda
announced in my EOSS talk that there should be a nicer way for
newcomers to set up builds than oe-init-build-env and that we're
working on it.
For no reason at all I was trying to avoid adding an interactive mode
:), but prompting users to make a selection will make things a lot
smoother. And each configuration should have a stable and sweet
shortcut name (at least, within a specific layer checkout), so that
awkward full paths are completely avoided. Maybe
{template-directory-name}-{layer-name}. I.e. 'default-meta-poky' or
'gizmo-meta-alex'.
Also, content of conf-notes.txt in oe-core/poky should be moved to the
first-time banner in scripts/oe-setup-builddir, and the files should
only point out that "This template sets up a default build
configuration used by Poky reference distribution" or similar.
Otherwise the tool will print what these files have now, which is not
helpful.
Should we be fine with just conf-notes.txt containing the template
description as a freeform plaintext, or is there a use case for more
structured template metadata?
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185137):
https://lists.openembedded.org/g/openembedded-core/message/185137
Mute This Topic: https://lists.openembedded.org/mt/98802403/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-