Re: New assignment operator?


Chen Qi
 

On 06/15/2021 06:29 PM, Richard Purdie wrote:
We have an interesting problem with initramfs images. They do something like:

IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"

which looks innocent enough until a BSP does:

IMAGE_FSTYPES_collie = "xxx"

where collie is MACHINE, hence an override which causes confusion as 
the value of INITRAMFS_FSTYPES is never used for that machine.

This is a long standing issue where in standard metadata, there is no way
to undo an override (or append/prepend/remove).

I tried to be clever and did:

python () {
    d.setVar("IMAGE_FSTYPES", d.getVar("INITRAMFS_FSTYPES"))
}

and if you do that before the image class inherit (since anon python is 
executed in the order it is defined), it nearly works. It doesn't work
with live images as IMAGE_FSTYPES is expanded for class inherits before
the anonymous python executes.

I also wondered about:

IMAGE_FSTYPES := "${INITRAMFS_FSTYPES}"

but that doesn't clear overrides either. In fact I can't actually see
a way to do it other than some horrible thing like:

def myfunc(d):
    d.setVar("IMAGE_FSTYPES", d.getVar("INITRAMFS_FSTYPES"))

DUMMYVAR := "${@myfunc(d)}"

Yes, we could do that but I don't think we should.

I wondered about making := clear existing overrides/appends/prepends/removes
but then I wondered if we should have a new assignment operator which
would do that (and also not force the value to be expanded). I mentioned this 
on irc and there were a few suggestions:

IMAGE_FSTYPES =!! "${INITRAMFS_FSTYPES}"

IMAGE_FSTYPES !=! "${INITRAMFS_FSTYPES}"

IMAGE_FSTYPES *:= "${INITRAMFS_FSTYPES}"

IMAGE_FSTYPES :=* "${INITRAMFS_FSTYPES}"

The questions are 
  a) is another assignment operator a good idea?

I think so.

1) In the view of compatibility, it's acceptable.   

Before the change, we have:
    _remove > _append > OVERRIDES > normal assignments

After the change, we have:
    !=! > _remove > _append > OVERRIDES > normal assignments

So it does not break anything

2) In the view of scope, it's necessary.

Recipe has smaller effective scope than conf file. Good design should be: it has higher priority than conf file.
The general principle is: smaller scope, higher priority.
For example, $HOME/.someconf beats /etc/someconf.
The current problem with bitbake/yocto/oe is that recipes cannot have the final call. They have smaller scope than conf files, yet are of the same priority regarding variable settings.
This problem can only be solved at the bitbake level. So adding a new assignment operator to let the recipe be able to make the final call is necessary.

  b) if so, which form? 

Implementation shouldn't be hard in bitbake, the APIs are already there to
do this kind of operation. I am kind of preferring !=!.

Any form is OK.
'!=!' seems a very natural choice for vi users. However, for users like me, it looks like 'never equals to' at a first glance.
Anyone proposed '==='? (I'm thinking about the 'always equal' sign in math.)
f(x) === C means no matter what x is, f always equals to C.
VAR(history) === C means no matter what the history is, the VAR always equals to C.
To clarify, I used 'VAR(history)' above to show that in bitbake a VAR's final value depends on its setting history.

Best Regards,
Chen Qi


Cheers,

Richard






Join openembedded-architecture@lists.openembedded.org to automatically receive all group messages.