RFC: handling of machine/distro features stuff

RFC: handling of machine/distro features stuff

[Marcin Juszkiewicz]

Currently OpenEmbedded use overrides based on DISTRO, MACHINE, TARGET_ARCH 
and few others. I want to suggest start of using also 
{MACHINE,DISTRO}_FEATURES because we have some stuff in metadata which 
make sense only on some targets only - for example madwifi is limited to 
PCI devices only.

Why do this at all? Let me take wpa-supplicant 0.5.x as example.

I'm building own distribution for my PDA devices and want to use latest 
possible software. But wpa-supplicant 0.5.1 depends on madwifi which 
cannot be build because my target device does not have PCI bus support. If 
I remove madwifi stuff from wpa-supplicant recipe then I will get working 
version. But this cannot be pushed back into repo because NSLU2 related 
distros want version with madwifi support.

Solution can be adding checking for pci support in 
{MACHINE,DISTRO}_FEATURES and only then enable madwifi support:

DEPENDS = "gnutls \ 
${@base_contains("DISTRO_FEATURES", "pci", "madwifi", "",d)}"

Same stuff can go into madwifi recipe so it will get skipped if target 
device lack PCI support.


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               Life's not fair. But the root password helps.

Re: RFC: handling of machine/distro features stuff

[Jamie Lenehan]

On Sun, Oct 29, 2006 at 03:28:39PM +0100, Marcin Juszkiewicz wrote:
> 
> Currently OpenEmbedded use overrides based on DISTRO, MACHINE, TARGET_ARCH 
> and few others. I want to suggest start of using also 
> {MACHINE,DISTRO}_FEATURES because we have some stuff in metadata which 
> make sense only on some targets only - for example madwifi is limited to 
> PCI devices only.

In general that sounds reasonable.

I've also run into problems before with things that depend on PCMCIA
which I don't have built into any of my kernels.

If you are going to do this it might be nice to make pci and mini-pci
separate features, since I don't want to build loads of pci device
and driver related stuff when my target devices only have mini-pci.
All my current mad-wifi cards for here are mini-pci.

[...]
> I remove madwifi stuff from wpa-supplicant recipe then I will get working 
> version. But this cannot be pushed back into repo because NSLU2 related 
> distros want version with madwifi support.

Yep. I need madwifi support in wpa-supplicant for my router distro
and associated target devices as well.

-- 
 Jamie Lenehan <lenehan@twibble.org>

Re: RFC: handling of machine/distro features stuff

[Justin Patrin]

On 10/29/06, Marcin Juszkiewicz <openembedded@hrw.one.pl> wrote:
>
> Currently OpenEmbedded use overrides based on DISTRO, MACHINE, TARGET_ARCH
> and few others. I want to suggest start of using also
> {MACHINE,DISTRO}_FEATURES because we have some stuff in metadata which
> make sense only on some targets only - for example madwifi is limited to
> PCI devices only.
>
> Why do this at all? Let me take wpa-supplicant 0.5.x as example.
>
> I'm building own distribution for my PDA devices and want to use latest
> possible software. But wpa-supplicant 0.5.1 depends on madwifi which
> cannot be build because my target device does not have PCI bus support. If
> I remove madwifi stuff from wpa-supplicant recipe then I will get working
> version. But this cannot be pushed back into repo because NSLU2 related
> distros want version with madwifi support.
>
> Solution can be adding checking for pci support in
> {MACHINE,DISTRO}_FEATURES and only then enable madwifi support:
>
> DEPENDS = "gnutls \
> ${@base_contains("DISTRO_FEATURES", "pci", "madwifi", "",d)}"
>
> Same stuff can go into madwifi recipe so it will get skipped if target
> device lack PCI support.
>

It *sounds* like what you want here is basically a USE-flag type of
system. Introducing it as FEATURES flags makes sense to me given that
OE is made for building embedded distros and not for local building,
as portage.

-- 
Justin Patrin

Re: RFC: handling of machine/distro features stuff

[Leon Woestenberg]

Hello all,

On 10/30/06, Justin Patrin <papercrane@gmail.com> wrote:
>
> It *sounds* like what you want here is basically a USE-flag type of
> system. Introducing it as FEATURES flags makes sense to me given that
> OE is made for building embedded distros and not for local building,
> as portage.
>
Yes, USE flags came to my mind as well when I read this.

In my use case (beware of pun) I have a package overlay of graphical
packages (freetype, pango, cairo, gtk) but without dependencies on X
support (they render to framebuffers).

So, I recon this would fall into the domain of a DISTRO FEATURE (i.e. "no X11")

However, could I *disable* a feature in the intended framework? (much
like with the plus and minus signs in the emerge USE case)

Regards,

Leon 'likewise'

Re: RFC: handling of machine/distro features stuff

[Marcin Juszkiewicz]

Dnia niedziela, 29 października 2006 15:28, Marcin Juszkiewicz napisał:
> Currently OpenEmbedded use overrides based on DISTRO, MACHINE,
> TARGET_ARCH and few others. I want to suggest start of using also
> {MACHINE,DISTRO}_FEATURES because we have some stuff in metadata which
> make sense only on some targets only - for example madwifi is limited
> to PCI devices only.

Holger 'zecke' Freyther pointed me to MacPorts and their 'variants'. After 
looking at them I think that those are other kind of our overrides.

Which points me to this idea: how about adding COMBINED_FEATURES into 
overrides? I do not know will it slow down BitBake or make metadata bit 
more ugly but it is kind of solution.

do_configure() {
	do something
}

do_configure_pci() {
	do something
	do something PCI related
}

would solve wpa-supplicant example. 

What do you think?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

        "To be or not to be that is the question.":
         every programmer knows the answer $2b or (not $2b) is $ff.

Re: RFC: handling of machine/distro features stuff

[Richard Purdie]

On Fri, 2006-11-17 at 01:01 +0100, Marcin Juszkiewicz wrote:
> Dnia niedziela, 29 października 2006 15:28, Marcin Juszkiewicz napisał:
> > Currently OpenEmbedded use overrides based on DISTRO, MACHINE,
> > TARGET_ARCH and few others. I want to suggest start of using also
> > {MACHINE,DISTRO}_FEATURES because we have some stuff in metadata which
> > make sense only on some targets only - for example madwifi is limited
> > to PCI devices only.
> 
> Holger 'zecke' Freyther pointed me to MacPorts and their 'variants'. After 
> looking at them I think that those are other kind of our overrides.
> 
> Which points me to this idea: how about adding COMBINED_FEATURES into 
> overrides? I do not know will it slow down BitBake or make metadata bit 
> more ugly but it is kind of solution.

Personally, I think its a bad idea as we have too many variables in this
field and it could end up with too much namespace pollution. We need to
keep our overrides lean :)

Also, this would automatically make any package machine specific and
make multimachine pointless (anything using COMBINED_FEATURES is machine
specific).

Richard

Re: RFC: handling of machine/distro features stuff

[Marcin Juszkiewicz]

Dnia piątek, 17 listopada 2006 10:25, Richard Purdie napisał:
> > Which points me to this idea: how about adding COMBINED_FEATURES into
> > overrides? I do not know will it slow down BitBake or make metadata
> > bit more ugly but it is kind of solution.

> Also, this would automatically make any package machine specific and
> make multimachine pointless (anything using COMBINED_FEATURES is machine
> specific).

Koen suggested other solution - marking packages MACHINE specific when
COMBINED_FEATURES are used. For example wpa-supplicant will get this:

DEPENDS = "gnutls ${@base_contains('COMBINED_FEATURES', 'pci', 'madwifi-ng', '',d)}"
PACKAGE_ARCH = "${@base_contains('COMBINED_FEATURES', 'pci', ${MACHINE}, ${TARGET_ARCH}, d)}"

export HAS_PCI = ${@base_contains('COMBINED_FEATURES', 'pci', 1, 0,d)}

do_configure () {
        install -m 0755 ${WORKDIR}/defconfig-gnutls  .config

        if [ "x$HAS_PCI" == "x1" ] then; do
                echo "CONFIG_DRIVER_MADWIFI=y" >> .config
                echo "CFLAGS += -I${STAGING_INCDIR}/madwifi-ng" >> .config
        fi
}

Opinions?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

        "To be or not to be that is the question.":
         every programmer knows the answer $2b or (not $2b) is $ff.

Re: RFC: handling of machine/distro features stuff

[Richard Purdie]

On Fri, 2006-11-24 at 17:03 +0100, Marcin Juszkiewicz wrote:
> Koen suggested other solution - marking packages MACHINE specific when
> COMBINED_FEATURES are used. For example wpa-supplicant will get this:
>[...]
> Opinions?

Looks good to me.

Cheers,

Richard