On Tue, 2024-01-09 at 11:31 +0000, Richard Purdie via
lists.openembedded.org wrote:
> On Mon, 2024-01-08 at 19:53 -0800, Khem Raj wrote:
> > On Mon, Jan 8, 2024 at 7:49 PM Khem Raj <raj.k...@gmail.com> wrote:
> > >
> > > On Mon, Jan 8, 2024 at 2:39 PM Richard Purdie
> > > <richard.pur...@linuxfoundation.org> wrote:
> > > >
> > > > On Mon, 2024-01-08 at 17:14 +0000, Ross Burton wrote:
> > > > > On 3 Jan 2024, at 14:59, Richard Purdie via lists.openembedded.org
> > > > > <richard.purdie=linuxfoundation....@lists.openembedded.org> wrote:
> > > > > > --- a/meta/classes-recipe/gnomebase.bbclass
> > > > > > +++ b/meta/classes-recipe/gnomebase.bbclass
> > > > > > @@ -28,7 +28,7 @@ FILES:${PN} += "${datadir}/application-registry \
> > > > > > FILES:${PN}-doc += "${datadir}/devhelp"
> > > > > >
> > > > > > GNOMEBASEBUILDCLASS ??= "meson"
> > > > > > -inherit ${GNOMEBASEBUILDCLASS} pkgconfig
> > > > > > +inherit_defer ${GNOMEBASEBUILDCLASS} pkgconfig
> > > > >
> > > > > Feels like this should be split into inherit pkgconfig and
> > > > > inher_defer ${GNOMEBASEBUILDCLASS}.
> > > >
> > > > I guess did it this way for ease in the patch, it won't really make
> > > > much difference either way, particularly for pkgconfig given how simple
> > > > that class is.
> > > >
> > > > >
> > > > > > +inherit populate_sdk_base
> > > > > > +IMGCLASSES += "${@['', 'populate_sdk_ext']['linux' in
> > > > > > d.getVar("SDK_OS")]}"
> > > > >
> > > > > Whilst you’re here change this to foo if bar else flob, this boolean
> > > > > subsetting idiom drives me insane.
> > > >
> > > > I don't really mixing up changes as it just makes review harder so
> > > > whilst I don't mind changing that, I think it should be done
> > > > separately.
> > > >
> > > > > > --- a/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> > > > > > +++ b/meta/recipes-graphics/xorg-driver/xorg-driver-common.inc
> > > > > > @@ -14,7 +14,7 @@ SRC_URI =
> > > > > > "${XORG_MIRROR}/individual/driver/${BPN}-${PV}${XORG_DRIVER_COMPRESSOR
> > > > > > FILES:${PN} += " ${libdir}/xorg/modules/drivers/*.so"
> > > > > >
> > > > > > XORGBUILDCLASS ??= "autotools"
> > > > > > -inherit ${XORGBUILDCLASS} pkgconfig features_check
> > > > > > +inherit_defer ${XORGBUILDCLASS} pkgconfig features_check
> > > > >
> > > > > As above.
> > > > >
> > > > > > -inherit autotools texinfo binconfig-disabled pkgconfig
> > > > > > ${PYTHON_INHERIT} python3native multilib_header
> > > > > > +inherit autotools texinfo binconfig-disabled pkgconfig
> > > > > > multilib_header
> > > > > > +inherit_defer ${PYTHON_INHERIT} python3native
> > > > >
> > > > > Why is python3native defered?
> > > >
> > > > In the past there were some ordering issues around the python classes
> > > > so I was just being careful not to cause more problems in the patchset
> > > > than I was already trying to debug. It probably isn't necessary but at
> > > > the time I wasn't 100% sure and there were bigger issues.
> > > >
> > > > I can make the above tweaks if they really bother you...
> > > >
> > >
> > > Look into evolution-data-server-native.bb from meta-gnome
> > > it inherits native and provides own default do_compile/do_install
> > > functions
> > >
> > > it now needs to use
> > > inherit_defer native
> > >
> > > which parses but then the functions provided by the recipe are overridden
> > > by ones from autotools class perhaps because it is deferred too ?
> > >
> >
> > To add a bit more
> > diff --git
> > a/meta-gnome/recipes-gnome/evolution-data-server/evolution-data-server-native.bb
> > b/meta-gnome/recipes-gnome/evolution-data-server/evolution-data-server-native.bb
> > index 8f5c9ffb67..e163576c02 100644
> > ---
> > a/meta-gnome/recipes-gnome/evolution-data-server/evolution-data-server-native.bb
> > +++
> > b/meta-gnome/recipes-gnome/evolution-data-server/evolution-data-server-native.bb
> > @@ -5,7 +5,7 @@ inherit_defer native
> > DEPENDS = "glib-2.0-native"
> >
> > # build native helpers
> > -do_compile() {
> > +do_compile:class-native() {
> > cd ${S}/src/camel
> > sed -i 's:#include "evolution-data-server-config.h"::g'
> > camel-gen-tables.c
> > ${CC} -o ${B}/camel-gen-tables camel-gen-tables.c ${CFLAGS} ${LDFLAGS}
> > @@ -17,7 +17,7 @@ do_compile() {
> > ${CC} -o ${B}/gen-western-table gen-western-table.c ${CFLAGS}
> > ${CFLAGS_glib} ${LDFLAGS} ${LDFLAGS_glib}
> > }
> >
> > -do_install() {
> > +do_install:class-native() {
> > install -d ${D}${bindir}
> > install -m 755 ${B}/* ${D}${bindir}
> > }
> >
> > works, but it seems wrong to do it like this
>
> This is the unfortunate corner case this change triggers unfortunately.
>
> The gnomebase class has a conditional variable for whether to use
> autotools or meson. This means meson/autotools are put into
> inherit_defer since they depend on the value of GNOMEBASEBUILDCLASS.
>
> This means autotools is deferred to after these variables are set and
> the values from the class override the originals. That said, autotools
> uses EXPORT_FUNCTIONS against do_compile this so it should not happen.
>
> I did dive into what is actually going on and the issue is that
> do_compile is an EXPORT_FUNCTION from both base.bbclass and from
> autotools.bbclass.
>
> export functions overwrite their own versions, the issue looks to be
> that the setting from base.bbclass sets the magic flag to say it is
> special and the new value from the recipe doesn't clear the magic flag.
> That would be a separate bug. I think we can improve the
> export_functions logic to fix that.
>
> I do agree this kind of issue isn't optimal however I think some of the
> current behaviours are probably worse and if we can move core classes
> away from deferred inherits (e.g. let gnome recipes pick autotools or
> meson directly), these issues should be rare.
There is a patch for bitbake on master-next which fixes
EXPORT_FUNCTIONS and adds tests for it. That should fix the issue here.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193460):
https://lists.openembedded.org/g/openembedded-core/message/193460
Mute This Topic: https://lists.openembedded.org/mt/103502916/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
