On Wed, Jun 16, 2021 at 2:22 AM Phil Blundell via
lists.openembedded.org <[email protected]> wrote:
>
> On Tue, Jun 15, 2021 at 10:59:40PM +0100, Richard Purdie wrote:
> > It certainly could be a solution to the problem but I worry that having
> > variables that users should touch and not touch and variables shadowing
> > other variables is going to get complex rather quickly, even when you just
> > consider how you document or "enforce" it. Do we want to encourage what
> > could become many more intermiediate variables? It does sound like we're
> > effectively starting to write class "functions" with a list of variables
> > they operate on which may or may not be a good thing depending on how
> > common it became.
>
> Yes, that's a fair point. As you say, I kind of have the sense that our
> classes are drifting towards being more like classes in a "real" programming
> language, complete with an actual API, and possibly we ought to start
> thinking about them more in those terms. As in, "if you include
> image.bbclass,
> this is the set of variables it takes as input, and you need to give them
> appropriate values".
>
> > From descriptions from others it sounds like people have creatively worked
> > around this kind of issue with stronger overrides which I'd not considered
> > and would also work, it is just a little ugly in a different way. I'd
> > consider
> > use of the forcevariable override in oe-core a metadata failing (much like
> > I view _remove similarly in core).
>
> I agree. Although it's true that _forcevariable probably would fix this
> particular issue I think there's a fair chance that it will just end up
> creating
> the opposite problem at some point in the future. I don't honestly think
> there
> is any situation where using _forcevariable in oe-core itself would be the
> right thing to do.
I'm not sure I understand this. Why is using the _forcevariable
override somehow worse than inventing a new assignment operator to do
the same thing?
If we want to make a rule that nothing in oe-core should ever
forcefully override a setting provided by a BSP then that's OK... but
then isn't that an argument that a new assignment operator to
forcefully assign to variables shouldn't be used in oe-core?
>> I suppose the other obvious tactical answer to the problem at hand is for
> meta-zaurus to stop using an override at all for what it's doing. Although
> possibly not quite so elegant, there's no reason that it couldn't do:
>
> IMAGE_FSTYPES = "ext3"
> # nb, include not require...
> include conf/machine/zaurus/${MACHINE}-special.conf
>
> and then in conf/machine/zaurus/collie-special.conf it could just set
> IMAGE_FSTYPES = "squashfs"
>
> directly without needing any kind of override. That said I don't entirely
> understand why meta-zaurus doesn't already have a collie.conf (assuming
> MACHINE=collie) where it could be doing this...
Rewriting the BSP would work but it's sidestepping the issue and
doesn't really scale well. There will always be BSP layers which need
to support a collection of machines and the obvious way to do that is
to use default values and machine specific overrides within the BSP
layer. Making a rule that BSP layers can't use overrides for certain
variables will cause confusion and frustration.
I think the solution should be either that oe-core doesn't rely on
modifying variables set by the BSP (ie the initramfs images should be
able to signal to the image.bbclass that they want to use
INITRAMFS_FSTYPES via some other method than modifying IMAGE_FSTYPES)
or that we agree that oe-core can forcefully override the BSP
variables in certain well defined cases (and then the _forcevariable
override appears to be a good solution).
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1249):
https://lists.openembedded.org/g/openembedded-architecture/message/1249
Mute This Topic: https://lists.openembedded.org/mt/83552628/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
