Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Date: Tue, 17 May 2011 15:31:37 +0100	[thread overview]
Message-ID: <1305642697.3424.249.camel@rex> (raw)
In-Reply-To: <1305625498.2429.158.camel@phil-desktop>

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




  reply	other threads:[~2011-05-17 14:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16  6:04 [PATCH 0/2] Adjust default distrovars Khem Raj
2011-05-16  6:04 ` [PATCH 1/2] default-distrovars.inc: Do not add DISTRO_EXTRA_RDEPENDS and DISTRO_EXTRA_RRECOMMENDS Khem Raj
2011-05-16  6:04 ` [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes Khem Raj
2011-05-16  6:58   ` Koen Kooi
2011-05-16  9:55     ` Khem Raj
2011-05-16 11:41       ` Richard Purdie
2011-05-16 13:11         ` Koen Kooi
2011-05-16 13:50           ` Richard Purdie
2011-05-16 15:43             ` Koen Kooi
2011-05-17  0:13   ` Richard Purdie
2011-05-17  9:17     ` Phil Blundell
2011-05-17  9:34       ` Richard Purdie
2011-05-17  9:44         ` Phil Blundell
2011-05-17 14:31           ` Richard Purdie [this message]
2011-05-17 14:40             ` Phil Blundell
2011-05-18  5:36           ` Khem Raj
2011-05-18  5:49     ` Khem Raj
2011-05-18  7:49     ` Khem Raj
2011-05-18  7:57       ` Richard Purdie
2011-05-18  8:12         ` Khem Raj
2011-05-18  8:47           ` Koen Kooi
2011-05-18  9:55             ` Khem Raj
2011-05-18  8:48         ` Frans Meulenbroeks
2011-05-18 10:09           ` Richard Purdie
2011-05-20  1:10 ` [PATCH 0/2] Adjust default distrovars Saul Wold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1305642697.3424.249.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox