On Mon, 2024-01-08 at 19:53 -0800, Khem Raj wrote: > On Mon, Jan 8, 2024 at 7:49 PM Khem Raj <[email protected]> wrote: > > > > On Mon, Jan 8, 2024 at 2:39 PM Richard Purdie > > <[email protected]> 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 > > > > <[email protected]> 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193453): https://lists.openembedded.org/g/openembedded-core/message/193453 Mute This Topic: https://lists.openembedded.org/mt/103502916/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
