gobject introspection fixes

meta/conf/bitbake.conf MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= "" · line 765

Quoted 6 lines · Andre McCurdy

-DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 gobject-introspection-data"

meta/conf/bitbake.conf +2 -1

-MACHINE_FEATURES_BACKFILL = "rtc gobject-introspection-data"
+DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5"
+MACHINE_FEATURES_BACKFILL = "rtc"

So every BSP (apart from the qemu ones) would need to add the feature to MACHINE_FEATURES?

Maybe we should remove from DISTRO backfill but keep backfilling for MACHINE features?

Ross

On Thu, Mar 17, 2016 at 10:31 AM, Burton, Ross <[email protected]

Quoted 15 lines

wrote:

meta/conf/bitbake.conf MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= "" · line 765

Quoted 6 lines · Andre McCurdy

-DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 gobject-introspection-data"

meta/conf/bitbake.conf +2 -1

-MACHINE_FEATURES_BACKFILL = "rtc gobject-introspection-data"
+DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5"
+MACHINE_FEATURES_BACKFILL = "rtc"

So every BSP (apart from the qemu ones) would need to add the feature to
MACHINE_FEATURES?

Quoted 3 lines

Maybe we should remove from DISTRO backfill but keep backfilling for MACHINE
features?

Or don't control via a MACHINE feature at all (which would also solve the package PACKAGE_ARCH issue) ?

Each CPU tuning file would then instead need to somehow express "this tuning target creates binaries which can / can't be run with qemu", but maybe that's an improvement too - isn't it better to define and maintain that information centrally in files controlled by oe-core rather than leave it up to BSPs to get right?

Quoted 20 lines · Andre McCurdy

On Thu, Mar 17, 2016 at 10:31 AM, Burton, Ross <[email protected]

Quoted 15 lines

wrote:

meta/conf/bitbake.conf MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= "" · line 765

Quoted 6 lines · Andre McCurdy

-DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 gobject-introspection-data"

meta/conf/bitbake.conf +2 -1

-MACHINE_FEATURES_BACKFILL = "rtc gobject-introspection-data"
+DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5"
+MACHINE_FEATURES_BACKFILL = "rtc"

So every BSP (apart from the qemu ones) would need to add the feature to
MACHINE_FEATURES?

Quoted 3 lines

Maybe we should remove from DISTRO backfill but keep backfilling for MACHINE
features?

Quoted 8 lines

Or don't control via a MACHINE feature at all (which would also solve the package PACKAGE_ARCH issue) ?

Each CPU tuning file would then instead need to somehow express "this tuning target creates binaries which can / can't be run with qemu", but maybe that's an improvement too - isn't it better to define and maintain that information centrally in files controlled by oe-core rather than leave it up to BSPs to get right?

MACHINE_FEATURES is a variable which represents the features the target hardware has. There is nothing which says "this must be set in MACHINE.conf". In fact there is significant precedent for setting up common include files which define the hardware properties.

If you look at one of my patches, it alters a core common include file to exclude introspection in a case where we can't use it (x32).

So I think we actually want the same thing which is for the common tune files to setup the right data.

We have made a decision to defaulting to introspection, rightly or wrongly. I'm also quite happy to disable it where we know qemu can't work and tune files are likely the right place to that.

I don't think this patchset is right.

Cheers,

Richard

Deciding if/how qemu can run binaries for each tuning target is already partially addressed by the QEMU_EXTRAOPTIONS logic in qemu.bbclass. My suggestion would be to somehow generalise that existing logic, so (at least for machines using one of the standard oe-core tuning files) the question "can qemu run binaries created for ${MACHINE}?" could be answered automatically.

Quoted 44 lines · Richard Purdie

Quoted 26 lines · Andre McCurdy

On Thu, Mar 17, 2016 at 10:31 AM, Burton, Ross <
[email protected]

Quoted 15 lines

wrote:

meta/conf/bitbake.conf MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= "" · line 765

Quoted 6 lines · Andre McCurdy

-DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 gobject-introspection-data"

meta/conf/bitbake.conf +2 -1

-MACHINE_FEATURES_BACKFILL = "rtc gobject-introspection-data"
+DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5"
+MACHINE_FEATURES_BACKFILL = "rtc"

So every BSP (apart from the qemu ones) would need to add the feature to
MACHINE_FEATURES?

Quoted 4 lines

Maybe we should remove from DISTRO backfill but keep backfilling
for MACHINE
features?

Or don't control via a MACHINE feature at all (which would also solve
the package PACKAGE_ARCH issue) ?

Quoted 9 lines

Each CPU tuning file would then instead need to somehow express "this
tuning target creates binaries which can / can't be run with qemu",
but maybe that's an improvement too - isn't it better to define and
maintain that information centrally in files controlled by oe -core
rather than leave it up to BSPs to get right?

MACHINE_FEATURES is a variable which represents the features the target
hardware has. There is nothing which says "this must be set in MACHINE.conf". In fact there is significant precedent for setting up
common include files which define the hardware properties.

Quoted 7 lines

If you look at one of my patches, it alters a core common include file
to exclude introspection in a case where we can't use it (x32).

So I think we actually want the same thing which is for the common tune
files to setup the right data.

Yes, I think so.

Deciding if/how qemu can run binaries for each tuning target is already partially addressed by the QEMU_EXTRAOPTIONS logic in qemu.bbclass. My suggestion would be to somehow generalise that existing logic, so (at least for machines using one of the standard oe-core tuning files) the question "can qemu run binaries created for ${MACHINE}?" could be answered automatically.

# Generating introspection data depends on a combination of native and
target

 # introspection tools, and qemu to run the target tools.
-DEPENDS_append = " gobject-introspection gobject-introspection-native
qemu-native"
+DEPENDS_append = " ${@bb.utils.contains('COMBINED_FEATURES',
'gobject-introspection-data', 'gobject-introspection
gobject-introspection-native qemu-native', '', d)}"

Quoted 9 lines · Andre McCurdy

# Generating introspection data depends on a combination of native and
target

 # introspection tools, and qemu to run the target tools.
-DEPENDS_append = " gobject-introspection gobject-introspection-native
qemu-native"
+DEPENDS_append = " ${@bb.utils.contains('COMBINED_FEATURES',
'gobject-introspection-data', 'gobject-introspection
gobject-introspection-native qemu-native', '', d)}"

Have you verified this works with g-i disabled and a clean sysroot? I'm thinking builds will still need at least some of this to provide the m4 macros.

Ross

Quoted 9 lines · Andre McCurdy

# Generating introspection data depends on a combination of native and
target

 # introspection tools, and qemu to run the target tools.
-DEPENDS_append = " gobject-introspection gobject-introspection-native
qemu-native"
+DEPENDS_append = " ${@bb.utils.contains('COMBINED_FEATURES',
'gobject-introspection-data', 'gobject-introspection
gobject-introspection-native qemu-native', '', d)}"

Have you verified this works with g-i disabled and a clean sysroot? I'm thinking builds will still need at least some of this to provide the m4 macros.

Quoted 12 lines · Ross

Quoted 9 lines · Andre McCurdy

# Generating introspection data depends on a combination of
native and
target

 # introspection tools, and qemu to run the target tools.

(quoted diff) +0 -2

-DEPENDS_append = " gobject-introspection gobject-introspection
-native

qemu-native"
+DEPENDS_append = " ${@bb.utils.contains('COMBINED_FEATURES', 'gobject-introspection-data', 'gobject-introspection

Quoted 8 lines

Quoted 2 lines

gobject-introspection-native qemu-native', '', d)}"

Have you verified this works with g-i disabled and a clean sysroot?
I'm
thinking builds will still need at least some of this to provide the m4
macros.

Even with gobject-introspection-data removed from DISTRO_FEATURES I'm seeing
couple recipes (our version of gst-*) failing with:

Quoted 5 lines

configure:22282: error: possibly undefined macro:
PKG_CONFIG_SYSROOT_DIR
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.

and PKG_CONFIG_SYSROOT_DIR is added by introspection.m4 from g-i patchset.

Even with gobject-introspection-data removed from DISTRO_FEATURES I'm seeing
couple recipes (our version of gst-*) failing with:

| configure:22282: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
| If this token and others are legitimate, please use
m4_pattern_allow.
| See the Autoconf documentation.

and PKG_CONFIG_SYSROOT_DIR is added by introspection.m4 from g-i patchset.

Quoted 10 lines

Even with gobject-introspection-data removed from DISTRO_FEATURES I'm seeing
couple recipes (our version of gst-*) failing with:

| configure:22282: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
| If this token and others are legitimate, please use
m4_pattern_allow.
| See the Autoconf documentation.

and PKG_CONFIG_SYSROOT_DIR is added by introspection.m4 from g-i patchset.

Disabling building of introspection data will not guarantee absence of build failures, I'm afraid. Some recipes will work just fine unchanged, but others, including gstreamer, do need custom fixing, usually because they have non-standard locations for m4 macros, or those macros themselves are non-standard. So you need to rebase your recipes on top of those available now in oe-core, and particularly this snippet will fix the immediate problem you have above:

delete_pkg_m4_file() {
# This m4 file is out of date and is missing
PKG_CONFIG_SYSROOT_PATH tweaks which we need for introspection

        rm "${S}/common/m4/pkg.m4" || true
}

do_configure[prefuncs] += " delete_pkg_m4_file"

Signed-off-by Andre McCurdy <[email protected]>

---
 meta/classes/gobject-introspection.bbclass | 3 +++
 1 file changed, 3 insertions(+)

meta/classes/gobject-introspection.bbclass +0 -0

index eb0e7ad..8a09e34 100644