[PATCH 0/2] Adjust default distrovars

[PATCH 0/2] Adjust default distrovars

[Khem Raj]

These changes make sure that uclibc based images still build
and some tasks do not get added forcibly to distros

Pull URL: git://git.openembedded.org/openembedded-core-contrib
  Branch: kraj/default-distro
  Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/default-distro

Thanks,
    Khem Raj <raj.khem@gmail.com>
---


Khem Raj (2):
  default-distrovars.inc: Do not add DISTRO_EXTRA_RDEPENDS and
    DISTRO_EXTRA_RRECOMMENDS
  tclibc-uclibc.inc: Append -uclibc only to target recipes

 meta/conf/distro/include/default-distrovars.inc |    3 ---
 meta/conf/distro/include/tclibc-uclibc.inc      |    5 ++---
 2 files changed, 2 insertions(+), 6 deletions(-)

-- 
1.7.4.1

[PATCH 1/2] default-distrovars.inc: Do not add DISTRO_EXTRA_RDEPENDS and DISTRO_EXTRA_RRECOMMENDS

[Khem Raj]

We otherwise get these added to image dependencies in distributions
and they may not want it but would like to use those variables

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/conf/distro/include/default-distrovars.inc |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc
index 9b1d0ee..1aa45c8 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -14,9 +14,6 @@ LOCALE_UTF8_ONLY ?= "0"
 
 DISTRO_FEATURES ?= "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci"
 
-DISTRO_EXTRA_RDEPENDS += "task-core-boot"
-DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
-
 IMAGE_FEATURES ?= ""
 
 # This is a list of packages that are used by the build system to build the distribution, they are not
-- 
1.7.4.1

[PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

Do not define DEPLOY_DIR_IMAGE
Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
recipes
Append -uclibc to STAGING_DIR_HOST only for target recipes.

These changes make sure that we still share the native sysroot

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/conf/distro/include/tclibc-uclibc.inc |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
index 27f6ec6..4bd313f 100644
--- a/meta/conf/distro/include/tclibc-uclibc.inc
+++ b/meta/conf/distro/include/tclibc-uclibc.inc
@@ -20,10 +20,9 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
 
 IMAGE_LINGUAS = ""
 
-DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
 DEPLOY_DIR_append = "-uclibc"
-STAGING_DIR_TARGET_append = "-uclibc"
-STAGING_DIR_HOST_append = "-uclibc"
+STAGING_DIR_TARGET_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk')]}"
+STAGING_DIR_HOST_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 'crosssdk')]}"
 SSTATE_MANIFESTS_append = "-uclibc"
 
 LIBC_DEPENDENCIES = "\
-- 
1.7.4.1

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Koen Kooi]

Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:

> Do not define DEPLOY_DIR_IMAGE
> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> recipes
> Append -uclibc to STAGING_DIR_HOST only for target recipes.
> 
> These changes make sure that we still share the native sysroot

I still stay we append tclibc unconditionally.

> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> meta/conf/distro/include/tclibc-uclibc.inc |    5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
> index 27f6ec6..4bd313f 100644
> --- a/meta/conf/distro/include/tclibc-uclibc.inc
> +++ b/meta/conf/distro/include/tclibc-uclibc.inc
> @@ -20,10 +20,9 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
> 
> IMAGE_LINGUAS = ""
> 
> -DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
> DEPLOY_DIR_append = "-uclibc"
> -STAGING_DIR_TARGET_append = "-uclibc"
> -STAGING_DIR_HOST_append = "-uclibc"
> +STAGING_DIR_TARGET_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk')]}"
> +STAGING_DIR_HOST_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 'crosssdk')]}"
> SSTATE_MANIFESTS_append = "-uclibc"
> 
> LIBC_DEPENDENCIES = "\
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

On Sun, May 15, 2011 at 11:58 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
>
>> Do not define DEPLOY_DIR_IMAGE
>> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
>> recipes
>> Append -uclibc to STAGING_DIR_HOST only for target recipes.
>>
>> These changes make sure that we still share the native sysroot
>
> I still stay we append tclibc unconditionally.

yes thats would simplify things if we agree to use TCLIBC in bitbake.conf

>
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>> meta/conf/distro/include/tclibc-uclibc.inc |    5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
>> index 27f6ec6..4bd313f 100644
>> --- a/meta/conf/distro/include/tclibc-uclibc.inc
>> +++ b/meta/conf/distro/include/tclibc-uclibc.inc
>> @@ -20,10 +20,9 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
>>
>> IMAGE_LINGUAS = ""
>>
>> -DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
>> DEPLOY_DIR_append = "-uclibc"
>> -STAGING_DIR_TARGET_append = "-uclibc"
>> -STAGING_DIR_HOST_append = "-uclibc"
>> +STAGING_DIR_TARGET_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk')]}"
>> +STAGING_DIR_HOST_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 'crosssdk')]}"
>> SSTATE_MANIFESTS_append = "-uclibc"
>>
>> LIBC_DEPENDENCIES = "\
>> --
>> 1.7.4.1
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Mon, 2011-05-16 at 02:55 -0700, Khem Raj wrote:
> On Sun, May 15, 2011 at 11:58 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >
> > Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
> >
> >> Do not define DEPLOY_DIR_IMAGE
> >> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> >> recipes
> >> Append -uclibc to STAGING_DIR_HOST only for target recipes.
> >>
> >> These changes make sure that we still share the native sysroot
> >
> > I still stay we append tclibc unconditionally.
> 
> yes thats would simplify things if we agree to use TCLIBC in bitbake.conf

We can't depend on TCLIBC in bitbake.conf since someone still has the
option of not using the standard configuration boilerplate we're
providing.

Cheers,

Richard

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Koen Kooi]

Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:

> On Mon, 2011-05-16 at 02:55 -0700, Khem Raj wrote:
>> On Sun, May 15, 2011 at 11:58 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> 
>>> Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
>>> 
>>>> Do not define DEPLOY_DIR_IMAGE
>>>> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
>>>> recipes
>>>> Append -uclibc to STAGING_DIR_HOST only for target recipes.
>>>> 
>>>> These changes make sure that we still share the native sysroot
>>> 
>>> I still stay we append tclibc unconditionally.
>> 
>> yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
> 
> We can't depend on TCLIBC in bitbake.conf since someone still has the
> option of not using the standard configuration boilerplate we're
> providing.

So we can't add TCLIBC ??= eglibc to bitbake.conf?

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Mon, 2011-05-16 at 15:11 +0200, Koen Kooi wrote:
> Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:
> 
> > On Mon, 2011-05-16 at 02:55 -0700, Khem Raj wrote:
> >> On Sun, May 15, 2011 at 11:58 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>> 
> >>> Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
> >>> 
> >>>> Do not define DEPLOY_DIR_IMAGE
> >>>> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> >>>> recipes
> >>>> Append -uclibc to STAGING_DIR_HOST only for target recipes.
> >>>> 
> >>>> These changes make sure that we still share the native sysroot
> >>> 
> >>> I still stay we append tclibc unconditionally.
> >> 
> >> yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
> > 
> > We can't depend on TCLIBC in bitbake.conf since someone still has the
> > option of not using the standard configuration boilerplate we're
> > providing.
> 
> So we can't add TCLIBC ??= eglibc to bitbake.conf?

No, I can just see the bug reports for uclibc building in a directory
called XXX-eglibc as the user had only set the PREFERRED_PROVIDER
variables.

Cheers,

Richard

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Koen Kooi]

Op 16 mei 2011, om 15:50 heeft Richard Purdie het volgende geschreven:

> On Mon, 2011-05-16 at 15:11 +0200, Koen Kooi wrote:
>> Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Mon, 2011-05-16 at 02:55 -0700, Khem Raj wrote:
>>>> On Sun, May 15, 2011 at 11:58 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>> 
>>>>> Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
>>>>> 
>>>>>> Do not define DEPLOY_DIR_IMAGE
>>>>>> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
>>>>>> recipes
>>>>>> Append -uclibc to STAGING_DIR_HOST only for target recipes.
>>>>>> 
>>>>>> These changes make sure that we still share the native sysroot
>>>>> 
>>>>> I still stay we append tclibc unconditionally.
>>>> 
>>>> yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
>>> 
>>> We can't depend on TCLIBC in bitbake.conf since someone still has the
>>> option of not using the standard configuration boilerplate we're
>>> providing.
>> 
>> So we can't add TCLIBC ??= eglibc to bitbake.conf?
> 
> No, I can just see the bug reports for uclibc building in a directory
> called XXX-eglibc as the user had only set the PREFERRED_PROVIDER
> variables.

Do you really care about such usecases? Someone who thinks he is too smart to use the includes can 'fix' the paths himself, no?

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Sun, 2011-05-15 at 23:04 -0700, Khem Raj wrote:
> Do not define DEPLOY_DIR_IMAGE
> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> recipes
> Append -uclibc to STAGING_DIR_HOST only for target recipes.
> 
> These changes make sure that we still share the native sysroot
> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>

The more I looked at that patch, the more holes I could see in what we
were doing (and what Angstrom currently does). I started playing around
with the patch below which tried to improve on that idea.

I then concluded that we might be able to do something like:

MACHINEOVERRIDES := "${MACHINE}"
MACHINE_append = "-uclibc"

since what we're really trying to do in the uclibc case is replace
anything MACHINE specific with something containing uclibc?

Thoughts?

Cheers,

Richard


diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 553c6a2..354668f 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -23,7 +23,7 @@ python () {
         bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)
     elif bb.data.inherits_class('cross', d):
         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
-        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d)
+        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${STAGING_MACHNAME}", d), d)
     elif bb.data.inherits_class('crosssdk', d):
         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
     elif bb.data.inherits_class('nativesdk', d):
@@ -31,7 +31,7 @@ python () {
     elif bb.data.inherits_class('cross-canadian', d):
         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
     else:
-        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d)
+        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${STAGING_MACHNAME}", d), d)
 
     # These classes encode staging paths into their scripts data so can only be
     # reused if we manipulate the paths
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index fef6457..c2e4e50 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -91,7 +91,7 @@ SSTATETASKS += "do_populate_sysroot"
 do_populate_sysroot[sstate-name] = "populate-sysroot"
 do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}"
 do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/"
-do_populate_sysroot[stamp-extra-info] = "${MACHINE}"
+do_populate_sysroot[stamp-extra-info] = "${STAGING_MACHNAME}"
 
 python do_populate_sysroot_setscene () {
 	sstate_setscene(d)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 8b6236e..141b942 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -300,7 +300,8 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}"
 
 # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine 
 # specific packages - hack around it for now.
-STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}"
+STAGING_MACHNAME ??= "${MACHINE}"
+STAGING_DIR_HOST = "${STAGING_DIR}/${STAGING_MACHNAME}"
 STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}"
 STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}"
 STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
@@ -312,7 +313,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"
 
 # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine 
 # specific packages - hack around it for now.
-STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}"
+STAGING_DIR_TARGET = "${STAGING_DIR}/${STAGING_MACHNAME}"
 STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap"
 
 # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
@@ -344,8 +345,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"
 
 IMAGE_ROOTFS = "${WORKDIR}/rootfs"
 IMAGE_BASENAME = "${PN}"
-IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
-IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
+IMAGE_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}-${DATETIME}"
+IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}"
 
 # This option allows for a precentage overage of the actaul image size rather than a
 # fixed extra space
diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
index 27f6ec6..e84da81 100644
--- a/meta/conf/distro/include/tclibc-uclibc.inc
+++ b/meta/conf/distro/include/tclibc-uclibc.inc
@@ -20,11 +20,7 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
 
 IMAGE_LINGUAS = ""
 
-DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
-DEPLOY_DIR_append = "-uclibc"
-STAGING_DIR_TARGET_append = "-uclibc"
-STAGING_DIR_HOST_append = "-uclibc"
-SSTATE_MANIFESTS_append = "-uclibc"
+STAGING_MACHNAME = "${MACHINE}-uclibc"
 
 LIBC_DEPENDENCIES = "\
     uclibc \

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Phil Blundell]

On Tue, 2011-05-17 at 01:13 +0100, Richard Purdie wrote:
> The more I looked at that patch, the more holes I could see in what we
> were doing (and what Angstrom currently does). I started playing around
> with the patch below which tried to improve on that idea.
> 
> I then concluded that we might be able to do something like:
> 
> MACHINEOVERRIDES := "${MACHINE}"
> MACHINE_append = "-uclibc"
> 
> since what we're really trying to do in the uclibc case is replace
> anything MACHINE specific with something containing uclibc?

I think that particular change would be a bad idea for several reasons.
Firstly, and perhaps most importantly, MACHINE is a primary
configuration variable and having it magically change under the hood
seems like it would violate the principle of least surprise.  Secondly,
at a practical level, this would make it hard to use MACHINE for
anything other than overrides.  And thirdly, at a conceptual level, the
choice of libc is really nothing to do with the MACHINE.

> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 553c6a2..354668f 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass

This patch looks good to me (and I would definitely prefer this to the
solution above).  The lines that you have deleted from tclibc-uclibc.inc
were causing my uclibc builds to fail so I would certainly be glad to
have them removed.

p.

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Tue, 2011-05-17 at 10:17 +0100, Phil Blundell wrote:
> On Tue, 2011-05-17 at 01:13 +0100, Richard Purdie wrote:
> > The more I looked at that patch, the more holes I could see in what we
> > were doing (and what Angstrom currently does). I started playing around
> > with the patch below which tried to improve on that idea.
> > 
> > I then concluded that we might be able to do something like:
> > 
> > MACHINEOVERRIDES := "${MACHINE}"
> > MACHINE_append = "-uclibc"
> > 
> > since what we're really trying to do in the uclibc case is replace
> > anything MACHINE specific with something containing uclibc?
> 
> I think that particular change would be a bad idea for several reasons.
> Firstly, and perhaps most importantly, MACHINE is a primary
> configuration variable and having it magically change under the hood
> seems like it would violate the principle of least surprise.  Secondly,
> at a practical level, this would make it hard to use MACHINE for
> anything other than overrides.  And thirdly, at a conceptual level, the
> choice of libc is really nothing to do with the MACHINE.
> 
> > diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> > index 553c6a2..354668f 100644
> > --- a/meta/classes/sstate.bbclass
> > +++ b/meta/classes/sstate.bbclass
> 
> This patch looks good to me (and I would definitely prefer this to the
> solution above).  The lines that you have deleted from tclibc-uclibc.inc
> were causing my uclibc builds to fail so I would certainly be glad to
> have them removed.

No question those lines are "wrong" but the solutions various people are
using out there are "wrong" in various ways too (including what is
'working' in ansgtrom at the moment).

A solution where you replace 80% of uses of a variable with a new
variable as per my proposed patch doesn't quite feel right either.

How about this idea:

TMPDIR_append = "-uclibc"

since sstate cache is deliberately outside TMPDIR so anything that can
be reused between builds will automatically.

Simple, effective and addresses a lot of the bugs I can see in the other
approaches...

Cheers,

Richard

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Phil Blundell]

On Tue, 2011-05-17 at 10:34 +0100, Richard Purdie wrote:
> How about this idea:
> 
> TMPDIR_append = "-uclibc"

Hm, I'm not totally sure what this really buys us.  

If the whole issue boils down to saying that you just can't share a
TMPDIR between builds with competing C libraries (which sounds
reasonable, since it's probably about the same thing as saying that libc
selection is a DISTRO property) then it seems like something that can be
fixed in the documentation.  Users can just select a different TMPDIR by
hand, same as they would when changing DISTROs, and it doesn't seem that
there is any real need for the build system to try to work around it for
them.

I'm also slightly uncomfortable with automagic TMPDIR frobbing for the
same reason as MACHINE; if I set TMPDIR="foo" in my local.conf then I
would have an (IMHO reasonable) expectation that the build artifacts
would actually go into that directory and not some variation on the
theme.  I guess you could ameliorate that slightly by appending
"/uclibc" so that at least you ended up using a subfolder of the chosen
path, but it still doesn't seem very wholesome to me.

p.

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Tue, 2011-05-17 at 10:44 +0100, Phil Blundell wrote:
> On Tue, 2011-05-17 at 10:34 +0100, Richard Purdie wrote:
> > How about this idea:
> > 
> > TMPDIR_append = "-uclibc"
> 
> Hm, I'm not totally sure what this really buys us.  
> 
> If the whole issue boils down to saying that you just can't share a
> TMPDIR between builds with competing C libraries (which sounds
> reasonable, since it's probably about the same thing as saying that libc
> selection is a DISTRO property) then it seems like something that can be
> fixed in the documentation.  Users can just select a different TMPDIR by
> hand, same as they would when changing DISTROs, and it doesn't seem that
> there is any real need for the build system to try to work around it for
> them.

Some distros want to be able to build multiple libc in the same tree in
the same way multiple machines work without requiring the user to switch
settings. I don't think its an unreasonable request but the
implementation shouldn't impact the system too adversely. I think this
fits that requirement.

> I'm also slightly uncomfortable with automagic TMPDIR frobbing for the
> same reason as MACHINE; if I set TMPDIR="foo" in my local.conf then I
> would have an (IMHO reasonable) expectation that the build artifacts
> would actually go into that directory and not some variation on the
> theme.  I guess you could ameliorate that slightly by appending
> "/uclibc" so that at least you ended up using a subfolder of the chosen
> path, but it still doesn't seem very wholesome to me.

Its not ideal but its nicer than the MACHINE workarounds IMO. We could
default to turning it off and let distros choose to turn it on if they
desire it too...

Cheers,

Richard

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Phil Blundell]

On Tue, 2011-05-17 at 15:31 +0100, Richard Purdie wrote:
> Its not ideal but its nicer than the MACHINE workarounds IMO. We could
> default to turning it off and let distros choose to turn it on if they
> desire it too...

That sounds like a good plan to me.  Or if it's literally just
"TMPDIR_append = ...", maybe we could leave it up to the distros to set
in their own config files.

p.

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

On Tue, May 17, 2011 at 2:44 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2011-05-17 at 10:34 +0100, Richard Purdie wrote:
>> How about this idea:
>>
>> TMPDIR_append = "-uclibc"
>
> Hm, I'm not totally sure what this really buys us.
>
> If the whole issue boils down to saying that you just can't share a
> TMPDIR between builds with competing C libraries (which sounds
> reasonable, since it's probably about the same thing as saying that libc
> selection is a DISTRO property) then it seems like something that can be
> fixed in the documentation.  Users can just select a different TMPDIR by
> hand, same as they would when changing DISTROs, and it doesn't seem that
> there is any real need for the build system to try to work around it for
> them.

there are certain parts of build process which could be shared e.g.
native sysroot
and nativesdk package builds across target system library selections.
and we build
a lot of native packages it will be good if they could be shared
secondly the all-*-* package builds could be shared as well. Similarly
multimachine build is another aspect which could share builds too
having selected same C library.

Many users of oe would be development tool vendors who have BSPs for
many processor boards and C libraries and they would like to have this
possibility

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

On Mon, May 16, 2011 at 5:13 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sun, 2011-05-15 at 23:04 -0700, Khem Raj wrote:
>> Do not define DEPLOY_DIR_IMAGE
>> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
>> recipes
>> Append -uclibc to STAGING_DIR_HOST only for target recipes.
>>
>> These changes make sure that we still share the native sysroot
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>
> The more I looked at that patch, the more holes I could see in what we
> were doing (and what Angstrom currently does). I started playing around
> with the patch below which tried to improve on that idea.
>
> I then concluded that we might be able to do something like:
>
> MACHINEOVERRIDES := "${MACHINE}"
> MACHINE_append = "-uclibc"
>
> since what we're really trying to do in the uclibc case is replace
> anything MACHINE specific with something containing uclibc?
>
> Thoughts?
>
> Cheers,
>
> Richard
>
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 553c6a2..354668f 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -23,7 +23,7 @@ python () {
>         bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)
>     elif bb.data.inherits_class('cross', d):
>         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
> -        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d)
> +        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${STAGING_MACHNAME}", d), d)
>     elif bb.data.inherits_class('crosssdk', d):
>         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
>     elif bb.data.inherits_class('nativesdk', d):
> @@ -31,7 +31,7 @@ python () {
>     elif bb.data.inherits_class('cross-canadian', d):
>         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
>     else:
> -        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d)
> +        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${STAGING_MACHNAME}", d), d)
>
>     # These classes encode staging paths into their scripts data so can only be
>     # reused if we manipulate the paths
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index fef6457..c2e4e50 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -91,7 +91,7 @@ SSTATETASKS += "do_populate_sysroot"
>  do_populate_sysroot[sstate-name] = "populate-sysroot"
>  do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}"
>  do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/"
> -do_populate_sysroot[stamp-extra-info] = "${MACHINE}"
> +do_populate_sysroot[stamp-extra-info] = "${STAGING_MACHNAME}"
>
>  python do_populate_sysroot_setscene () {
>        sstate_setscene(d)
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 8b6236e..141b942 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -300,7 +300,8 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}"
>
>  # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine
>  # specific packages - hack around it for now.
> -STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}"
> +STAGING_MACHNAME ??= "${MACHINE}"
> +STAGING_DIR_HOST = "${STAGING_DIR}/${STAGING_MACHNAME}"
>  STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}"
>  STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}"
>  STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
> @@ -312,7 +313,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"
>
>  # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine
>  # specific packages - hack around it for now.
> -STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}"
> +STAGING_DIR_TARGET = "${STAGING_DIR}/${STAGING_MACHNAME}"
>  STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap"
>
>  # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
> @@ -344,8 +345,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"
>
>  IMAGE_ROOTFS = "${WORKDIR}/rootfs"
>  IMAGE_BASENAME = "${PN}"
> -IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
> -IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
> +IMAGE_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}-${DATETIME}"
> +IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}"
>
>  # This option allows for a precentage overage of the actaul image size rather than a
>  # fixed extra space
> diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
> index 27f6ec6..e84da81 100644
> --- a/meta/conf/distro/include/tclibc-uclibc.inc
> +++ b/meta/conf/distro/include/tclibc-uclibc.inc
> @@ -20,11 +20,7 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
>
>  IMAGE_LINGUAS = ""
>
> -DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
> -DEPLOY_DIR_append = "-uclibc"
> -STAGING_DIR_TARGET_append = "-uclibc"
> -STAGING_DIR_HOST_append = "-uclibc"
> -SSTATE_MANIFESTS_append = "-uclibc"
> +STAGING_MACHNAME = "${MACHINE}-uclibc"

should we use ${MACHINE}/${TCLIBC} in all those places instead of
defining STAGING_MACHNAME

>
>  LIBC_DEPENDENCIES = "\
>     uclibc \
>
>

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5520 bytes --]

On (17/05/11 01:13), Richard Purdie wrote:
> On Sun, 2011-05-15 at 23:04 -0700, Khem Raj wrote:
> > Do not define DEPLOY_DIR_IMAGE
> > Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> > recipes
> > Append -uclibc to STAGING_DIR_HOST only for target recipes.
> > 
> > These changes make sure that we still share the native sysroot
> > 
> > Signed-off-by: Khem Raj <raj.khem@gmail.com>
> 
> The more I looked at that patch, the more holes I could see in what we
> were doing (and what Angstrom currently does). I started playing around
> with the patch below which tried to improve on that idea.
> 
> I then concluded that we might be able to do something like:
> 
> MACHINEOVERRIDES := "${MACHINE}"
> MACHINE_append = "-uclibc"
> 
> since what we're really trying to do in the uclibc case is replace
> anything MACHINE specific with something containing uclibc?
> 
> Thoughts?
> 
> Cheers,
> 
> Richard
> 
> 
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 553c6a2..354668f 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -23,7 +23,7 @@ python () {
>          bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)
>      elif bb.data.inherits_class('cross', d):
>          bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
> -        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d)
> +        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${STAGING_MACHNAME}", d), d)
>      elif bb.data.inherits_class('crosssdk', d):
>          bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
>      elif bb.data.inherits_class('nativesdk', d):
> @@ -31,7 +31,7 @@ python () {
>      elif bb.data.inherits_class('cross-canadian', d):
>          bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
>      else:
> -        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d)
> +        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${STAGING_MACHNAME}", d), d)
>  
>      # These classes encode staging paths into their scripts data so can only be
>      # reused if we manipulate the paths
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index fef6457..c2e4e50 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -91,7 +91,7 @@ SSTATETASKS += "do_populate_sysroot"
>  do_populate_sysroot[sstate-name] = "populate-sysroot"
>  do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}"
>  do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/"
> -do_populate_sysroot[stamp-extra-info] = "${MACHINE}"
> +do_populate_sysroot[stamp-extra-info] = "${STAGING_MACHNAME}"
>  
>  python do_populate_sysroot_setscene () {
>  	sstate_setscene(d)
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 8b6236e..141b942 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -300,7 +300,8 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}"
>  
>  # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine 
>  # specific packages - hack around it for now.
> -STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}"
> +STAGING_MACHNAME ??= "${MACHINE}"
> +STAGING_DIR_HOST = "${STAGING_DIR}/${STAGING_MACHNAME}"
>  STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}"
>  STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}"
>  STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
> @@ -312,7 +313,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"
>  
>  # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine 
>  # specific packages - hack around it for now.
> -STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}"
> +STAGING_DIR_TARGET = "${STAGING_DIR}/${STAGING_MACHNAME}"
>  STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap"
>  
>  # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
> @@ -344,8 +345,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"
>  
>  IMAGE_ROOTFS = "${WORKDIR}/rootfs"
>  IMAGE_BASENAME = "${PN}"
> -IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
> -IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
> +IMAGE_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}-${DATETIME}"
> +IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}"
>  
>  # This option allows for a precentage overage of the actaul image size rather than a
>  # fixed extra space
> diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
> index 27f6ec6..e84da81 100644
> --- a/meta/conf/distro/include/tclibc-uclibc.inc
> +++ b/meta/conf/distro/include/tclibc-uclibc.inc
> @@ -20,11 +20,7 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
>  
>  IMAGE_LINGUAS = ""
>  
> -DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
> -DEPLOY_DIR_append = "-uclibc"
> -STAGING_DIR_TARGET_append = "-uclibc"
> -STAGING_DIR_HOST_append = "-uclibc"
> -SSTATE_MANIFESTS_append = "-uclibc"
> +STAGING_MACHNAME = "${MACHINE}-uclibc"
>  
>  LIBC_DEPENDENCIES = "\
>      uclibc \
> 

I think we need to globalize libc variable like MACHINE or MULTIMACHINE
and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
in base.bbclass for sanity. Something like attached patch might be
able to do it


-- 
-Khem

[-- Attachment #2: a.txt --]
[-- Type: text/plain, Size: 4281 bytes --]

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 23095ec..76642be 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -179,7 +179,11 @@ python base_eventhandler() {
 				pesteruser.append(v)
 		if pesteruser:
 			bb.fatal('The following variable(s) were not set: %s\nPlease set them directly, or choose a MACHINE or DISTRO that sets them.' % ', '.join(pesteruser))
-
+	if name == "ParseCompleted":
+		libc = bb.data.getVar('TCLIBC', e.data, True)
+		virtual_libc = bb.data.getVar('PREFERRED_PROVIDER_virtual/libc', e.data, True)
+		if not libc or libc != virtual_libc:
+			bb.fatal('PREFERRED_PROVIDER_virtual/libc = %s and TCLIBC = %s, they should be same.' % (virtual_libc, libc))
         if name == "ConfigParsed":
                 generate_git_config(e)
 
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 553c6a2..dbd046a 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -23,7 +23,7 @@ python () {
         bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)
     elif bb.data.inherits_class('cross', d):
         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
-        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d)
+        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}_${TCLIBC}", d), d)
     elif bb.data.inherits_class('crosssdk', d):
         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
     elif bb.data.inherits_class('nativesdk', d):
@@ -31,7 +31,7 @@ python () {
     elif bb.data.inherits_class('cross-canadian', d):
         bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
     else:
-        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d)
+        bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}_${TCLIBC}", d), d)
 
     # These classes encode staging paths into their scripts data so can only be
     # reused if we manipulate the paths
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index fef6457..856efd8 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -92,6 +92,7 @@ do_populate_sysroot[sstate-name] = "populate-sysroot"
 do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}"
 do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/"
 do_populate_sysroot[stamp-extra-info] = "${MACHINE}"
+do_populate_sysroot[stamp-extra-info] = "${TCLIBC}"
 
 python do_populate_sysroot_setscene () {
 	sstate_setscene(d)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index c292759..6f2d64a 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -300,7 +300,7 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}"
 
 # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine 
 # specific packages - hack around it for now.
-STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}"
+STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}-${TCLIBC}"
 STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}"
 STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}"
 STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
@@ -312,7 +312,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"
 
 # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine 
 # specific packages - hack around it for now.
-STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}"
+STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}-${TCLIBC}"
 STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap"
 
 # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
@@ -344,8 +344,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"
 
 IMAGE_ROOTFS = "${WORKDIR}/rootfs"
 IMAGE_BASENAME = "${PN}"
-IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
-IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
+IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${TCLIBC}-${DATETIME}"
+IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}-${TCLIBC}"
 
 # This option allows for a precentage overage of the actaul image size rather than a
 # fixed extra space

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
> I think we need to globalize libc variable like MACHINE or MULTIMACHINE
> and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
> in base.bbclass for sanity. Something like attached patch might be
> able to do it

Having assessed how many places in the system we'd need to make this
kind of change I'm now of the opinion its too great. I think
manipulating TMPDIR is a better cleaner solution and we should inject
this there...

Cheers,

Richard

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

On (18/05/11 08:57), Richard Purdie wrote:
> On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
> > I think we need to globalize libc variable like MACHINE or MULTIMACHINE
> > and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
> > in base.bbclass for sanity. Something like attached patch might be
> > able to do it
> 
> Having assessed how many places in the system we'd need to make this
> kind of change I'm now of the opinion its too great. I think
> manipulating TMPDIR is a better cleaner solution and we should inject
> this there...

hmmm ok. So we delete these definitions from tclibc-uclibc.inc

DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
DEPLOY_DIR_append = "-uclibc"
STAGING_DIR_TARGET_append = "-uclibc"
STAGING_DIR_HOST_append = "-uclibc"
SSTATE_MANIFESTS_append = "-uclibc"

and append define
TMPDIR ?= "${TOPDIR}/tmp-${TCLIBC}"

should be enough
> 
> Cheers,
> 
> Richard
> 

-- 
-Khem

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Koen Kooi]

Op 18 mei 2011, om 10:12 heeft Khem Raj het volgende geschreven:

> On (18/05/11 08:57), Richard Purdie wrote:
>> On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
>>> I think we need to globalize libc variable like MACHINE or MULTIMACHINE
>>> and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
>>> in base.bbclass for sanity. Something like attached patch might be
>>> able to do it
>> 
>> Having assessed how many places in the system we'd need to make this
>> kind of change I'm now of the opinion its too great. I think
>> manipulating TMPDIR is a better cleaner solution and we should inject
>> this there...
> 
> hmmm ok. So we delete these definitions from tclibc-uclibc.inc
> 
> DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
> DEPLOY_DIR_append = "-uclibc"
> STAGING_DIR_TARGET_append = "-uclibc"
> STAGING_DIR_HOST_append = "-uclibc"
> SSTATE_MANIFESTS_append = "-uclibc"
> 
> and append define
> TMPDIR ?= "${TOPDIR}/tmp-${TCLIBC}"
> 
> should be enough

Like this: http://patches.openembedded.org/patch/4229/ ?

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Khem Raj]

On Wed, May 18, 2011 at 1:47 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 18 mei 2011, om 10:12 heeft Khem Raj het volgende geschreven:
>
>> On (18/05/11 08:57), Richard Purdie wrote:
>>> On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
>>>> I think we need to globalize libc variable like MACHINE or MULTIMACHINE
>>>> and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
>>>> in base.bbclass for sanity. Something like attached patch might be
>>>> able to do it
>>>
>>> Having assessed how many places in the system we'd need to make this
>>> kind of change I'm now of the opinion its too great. I think
>>> manipulating TMPDIR is a better cleaner solution and we should inject
>>> this there...
>>
>> hmmm ok. So we delete these definitions from tclibc-uclibc.inc
>>
>> DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
>> DEPLOY_DIR_append = "-uclibc"
>> STAGING_DIR_TARGET_append = "-uclibc"
>> STAGING_DIR_HOST_append = "-uclibc"
>> SSTATE_MANIFESTS_append = "-uclibc"
>>
>> and append define
>> TMPDIR ?= "${TOPDIR}/tmp-${TCLIBC}"
>>
>> should be enough
>
> Like this: http://patches.openembedded.org/patch/4229/ ?


yes exactly looks good to me.

>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Frans Meulenbroeks]

2011/5/18 Richard Purdie <richard.purdie@linuxfoundation.org>

> On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
> > I think we need to globalize libc variable like MACHINE or MULTIMACHINE
> > and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
> > in base.bbclass for sanity. Something like attached patch might be
> > able to do it
>
> Having assessed how many places in the system we'd need to make this
> kind of change I'm now of the opinion its too great. I think
> manipulating TMPDIR is a better cleaner solution and we should inject
> this there...
>
>
> Note that this introduces  additional build time and space to rebuild
native recipes for the different TMPDIR variants. Something which is not
needed with the solution from Khem, if I properly understand things.

From a conceptual point of view it seems better to mangle the target subdir
name  in work (e.g. ppce300c3-oe-linux-uclibc) or introduce a subdir in
TMPDIR for  (e.g. ppce300c3-oe-linux/uclibc )

(actually I seem to recall that we have or had something in OE as well,
something like deploy/glibc)

Frans

Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Wed, 2011-05-18 at 10:48 +0200, Frans Meulenbroeks wrote:
> 2011/5/18 Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> > On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
> > > I think we need to globalize libc variable like MACHINE or MULTIMACHINE
> > > and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
> > > in base.bbclass for sanity. Something like attached patch might be
> > > able to do it
> >
> > Having assessed how many places in the system we'd need to make this
> > kind of change I'm now of the opinion its too great. I think
> > manipulating TMPDIR is a better cleaner solution and we should inject
> > this there...
> >
> >
> > Note that this introduces  additional build time and space to rebuild
> native recipes for the different TMPDIR variants. Something which is not
> needed with the solution from Khem, if I properly understand things.

I mentioned this elsewhere in the thread but the sstate cache directory
is in TOPDIR, not TMPDIR so its shared between the builds. This means
the -native recipes should not need any additional build time. There is
some disk space usage but this should be minimal and disk space is
comparatively cheap anyway.

> From a conceptual point of view it seems better to mangle the target subdir
> name  in work (e.g. ppce300c3-oe-linux-uclibc) or introduce a subdir in
> TMPDIR for  (e.g. ppce300c3-oe-linux/uclibc )

This turns out to be quite nasty mangling as the deploy directories
don't include this and would need mangling in a certain style, the
sysroots need a different mangling and so does workdir, the cache
directories and so on. What these all have in common is they're in
TMPDIR and the native directories are pretty much the only thing we
don't mangle. The exceptions to the mangling seem to work out quite ugly
as in the cross case we have to "half-mangle" directories too.

> (actually I seem to recall that we have or had something in OE as 
> well, something like deploy/glibc)

Some of it worked ok in OE, some of it didn't and the move to a sysroot
directory per machine was the straw that broke the camel's back so to
speak. We need to take a step back and consider what we're trying to
achieve from an overall architecture perspective and which solution
makes sense.

Cheers,

Richard

Re: [PATCH 0/2] Adjust default distrovars

[Saul Wold]

On 05/15/2011 11:04 PM, Khem Raj wrote:
> These changes make sure that uclibc based images still build
> and some tasks do not get added forcibly to distros
>
> Pull URL: git://git.openembedded.org/openembedded-core-contrib
>    Branch: kraj/default-distro
>    Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/default-distro
>
> Thanks,
>      Khem Raj<raj.khem@gmail.com>
> ---
>
>
> Khem Raj (2):
>    default-distrovars.inc: Do not add DISTRO_EXTRA_RDEPENDS and
>      DISTRO_EXTRA_RRECOMMENDS
Was merged into oe-core

>    tclibc-uclibc.inc: Append -uclibc only to target recipes
>
Clearly there has been some discussion about this one ;-)!
Richard merged the TMPDIR_append.

>   meta/conf/distro/include/default-distrovars.inc |    3 ---
>   meta/conf/distro/include/tclibc-uclibc.inc      |    5 ++---
>   2 files changed, 2 insertions(+), 6 deletions(-)
>
Thanks
	Sau!