From: Chris Conroy <Chris.Conroy@hillcrestlabs.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script
Date: Thu, 04 Feb 2010 13:42:50 -0500 [thread overview]
Message-ID: <1265308970.13632.6.camel@conroy-linux> (raw)
In-Reply-To: <20100204172234.GA5641@denix.org>
On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> First of all, they are the same. Check conf/bitbake.conf:
>
> SDKPATH = "${SDK_PATH}"
>
> Second, ask RP why he introduced SDKPATH, when we had SDK_PATH for years (my
> guess - that's what is used in Poky, so makes porting changes easier):
Fair enough, but saying 'ask RP' doesn't justify away the fact that
having these two variables is confusing. If they really are the same,
then one should be removed. If one shouldn't be removed, then there is
some difference that should probably be documented. It's just a matter
of consistency/readability.
> 7c2bd627 (Richard Purdie 2009-11-12 11:51:18 +0000 342) SDKPATH = "${SDK_PATH}"
>
> > renamed since having them both will be a source of confusion.
> >
> > It should probably be ${SDK_PATH} instead of $SDK_PATH in your changes.
>
> You missed the whole point of the patch. It really should be $SDK_PATH
My bad there. I got hung up on the SDK_PATH/SDKPATH thing.
>
> > Does this really make the SDK relocatable? I thought there were still
> > major issues with relocating GCC.
>
> GCC built from OE may still have relocation problems - haven't checked lately.
> But it doesn't mean that's the only use case scenario... There is also
> external toolchain option, as well as building SDK without the toolchain.
> Both of those cases were tested with the above change for several months now.
>
next prev parent reply other threads:[~2010-02-04 18:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 1:43 [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script Denys Dmytriyenko
2010-02-04 16:57 ` Chris Conroy
2010-02-04 17:22 ` Denys Dmytriyenko
2010-02-04 17:57 ` Tom Rini
2010-02-06 13:04 ` Phil Blundell
2010-02-08 19:00 ` Tom Rini
2010-02-09 20:08 ` Khem Raj
2010-02-09 21:36 ` Tom Rini
2010-02-10 15:50 ` Richard Purdie
2010-02-10 18:45 ` Tom Rini
2010-02-10 18:54 ` Phil Blundell
2010-02-04 18:42 ` Chris Conroy [this message]
2010-02-04 19:07 ` Denys Dmytriyenko
2010-02-08 23:31 ` Richard Purdie
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=1265308970.13632.6.camel@conroy-linux \
--to=chris.conroy@hillcrestlabs.com \
--cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.