[OE-core] [PATCH 0/2] Extensible SDK improvements
Richard Purdie
richard.purdie at linuxfoundation.org
Sat Mar 7 16:20:53 UTC 2020
On Sat, 2020-03-07 at 15:55 +0100, Adrian Freihofer wrote:
> On Sat, 2020-03-07 at 12:40 +0000, Richard Purdie wrote:
> > On Sat, 2020-03-07 at 12:54 +0100, Adrian Freihofer wrote:
> > > Hi Richard,
> > >
> > > We have found two already supported ways to copy variables from
> > > the
> > > bitbake environment local.conf to the eSDK local.conf
> > >
> > > If a variable is defined in the local.conf bitbake environment,
> > > SDK_LOCAL_CONF_WHITELIST and SDK_LOCAL_CONF_BLACKLIST can be used
> > > to
> > > add it to the local.conf eSDK file.
> > >
> > > If a variable should be statically defined for the eSDK but not
> > > for
> > > the
> > > bitbake environment, sdk-extra.conf is useful.
> > >
> > > Now we would like to add a third way to add variables which are
> > > dynamically calculated by bitbake but need to be statically added
> > > to
> > > the eSDK local.conf. For example we would like to support
> > > something
> > > like that:
> > >
> > > def get_version_from_git(d):
> > > version = d.getVar("GIT_VERSION", True)
> > > if version:
> > > return version # runs in eSDK
> > > else:
> > > return bb.process.run("git... # runs in bitbake
> > >
> > > GIT_VERSION := "${@get_version_from_git(d)}"
> > >
> > > SDK_LOCAL_CONF_EXTRALIST_append = " GIT_VERSION"
> >
> > This worries me a bit since it means the eSDK and the "real" build
> > can
> > behave differently. I appreciate that can happen even with the
> > other
> > variables and means of setting them but this takes it to a new
> > level.
> >
> That I understand. The usage of the SDK_LOCAL_CONF_EXTRALIST would be
> very specific. Wrong usage would lead to a broken sstate in the eSDK.
>
> > Ultimately I think we're aiming to have normal builds convert into
> > an
> > eSDK and vice versa more easily. This seems to pull us further away
> > from that :/.
> >
> > What is the reasoning for having them behaving differently?
>
> Our goal is to equate the eSDK behavior with the behavior of the real
> build, also for the example with the GIT_VERSION, which bitbake and
> git
> will dynamically evaluate at eSDK build time.
>
> Suppose we want to compile the GIT_VERSION (last tag) from poky
> without
> any manual steps into the firmware. bitbake can simply call
>
> $ describe git --tags --dirty
> uninative-2,8-74-g56446f4570-dirty
>
> With Bitbake the variable can change. But in eSDK the GIT_VERSION
> must
> be a constant. The above function behaves like a constant if
> GIT_VERSION is defined in the local.conf for example. But it has a
> dynamic behavior if GIT_VERSION is undefined. The only missing part
> in
> the current Poky, is a way to automatically write the value to the
> local.conf of the eSDK. I don't think this would be much different
> than
> the already existing sdk-extra.conf file.
I've been thinking about this further. Why is any of this in local.conf
in the first place?
I'd suggest the bulk of it should be in your distro or class files?
I understand we do need some simple changes to local.conf in many cases
but any complex logic really should not be there. The above does look
like more complex logic to me...
I'm therefore leaning towards saying no to this patch, its just going
to cause us problems in the future.
Cheers,
Richard
More information about the Openembedded-core
mailing list