Hi Richard,
We are going to handle that in our own layer. That's fine. Thank you
for the timely clarification anyway.
Regards,
Adrian
On Sat, 2020-03-07 at 16:20 +0000, Richard Purdie wrote:
> 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
>
>
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
