From: Tom Rini <trini@kernel.crashing.org>
To: openembedded-devel@openembedded.org
Subject: Re: RFC: "Virtual" native and sdk recipes
Date: Thu, 1 Jan 2009 15:02:29 -0700 [thread overview]
Message-ID: <20090101220229.GH7040@smtp.west.cox.net> (raw)
In-Reply-To: <1230840687.5320.56.camel@dax.rpnet.com>
On Thu, Jan 01, 2009 at 08:11:27PM +0000, Richard Purdie wrote:
>
> On Thu, 2009-01-01 at 11:25 -0700, Tom Rini wrote:
> > On Thu, Jan 01, 2009 at 04:25:14PM +0000, Richard Purdie wrote:
> >
> > > Its nice to try something a bit different occasionally. For a long time
> > > the mechanical repetitive nature of -native and -sdk recipes has
> > > bothered me and people have talked about getting rid of them since
> > > forever. I've had ideas floating around on how to address this for a
> > > while and I now have a proper proposal and better still a proof of
> > > concept.
> >
> > I'll read the whole thing again later, but in working on the canadian
> > SDK stuff (*poke*) I've been thinking why don't we just build the "SDK"
> > packages for building our own stuff? gcc/etc are relocatible if we
> > build them right...
>
> Even if gcc is relocatable, some software (quilt springs to mind) has to
> be built using the paths it will be installed to. I'll happily support
> any effort to make as much as possible support relocation but at the
> very least we'll continue having -native packages and its them this is
> primarily aimed at. I wouldn't want to miss the opportunity to kill off
> many of the -sdk packages in poky at the same time though!
I know for quilt specifically anything you can compile in as a path you
can override in quiltrc, and you can pass-in --quiltrc, so... next? :)
But yes, I too wouldn't mind having a few less -sdk packages in my own
stuff too.
> I've been wondering how much the canadian SDK code will benefit from
> this and perhaps you can give some input on that?
Off the top of my head, it depends on if we want to allow one env to
make both a Linux and a Windows SDK. The foo-canadian-sdk packages can
fit very easily into any reuse scheme (the gcc ones look like all of the
others now). I was thinking there's no reason really (esp if we build
gcc correctly for relcation, which we don't now) that any 'target gcc
for sdk' recipe couldn't build for any one Linux or Windows target, but
not both. For my needs, I want both Linux and Windows SDKs kicked out
from one bitbake invokation.
--
Tom Rini
next prev parent reply other threads:[~2009-01-01 22:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-01 16:25 RFC: "Virtual" native and sdk recipes Richard Purdie
2009-01-01 18:11 ` Koen Kooi
2009-01-01 20:07 ` Richard Purdie
2009-01-01 18:25 ` Tom Rini
2009-01-01 20:11 ` Richard Purdie
2009-01-01 22:02 ` Tom Rini [this message]
2009-01-02 1:11 ` Richard Purdie
2009-01-02 4:37 ` Native/Cross/SDK rethink (Was: Re: RFC: "Virtual" native and sdk recipes) Tom Rini
2009-01-05 14:31 ` Esben Haabendal
2009-01-05 15:42 ` Tom Rini
2009-01-05 17:29 ` Koen Kooi
2009-01-05 19:53 ` Tom Rini
2009-01-06 20:51 ` Esben Haabendal
2009-01-07 0:14 ` Richard Purdie
2009-01-07 0:45 ` Tom Rini
2009-01-08 22:59 ` Leon Woestenberg
2009-01-09 0:54 ` RFC: "Virtual" native and sdk recipes Richard Purdie
2009-01-09 1:16 ` Tom Rini
2009-01-12 19:09 ` Tom Rini
2009-01-12 20:30 ` Esben Haabendal
2009-01-09 17:04 ` Tom Rini
2009-01-12 20:47 ` Tom Rini
2009-01-10 15:33 ` Tom Rini
2009-01-10 19:06 ` Tom Rini
2009-01-14 1:15 ` Tom Rini
2009-01-14 23:17 ` Tom Rini
2009-01-17 2:54 ` Tom Rini
2009-01-17 4:47 ` Tom Rini
2009-01-22 18:10 ` Tom Rini
2009-01-28 19:49 ` Tom Rini
2009-01-01 22:15 ` Tom Rini
2009-01-01 23:19 ` Richard Purdie
2009-01-03 11:17 ` Richard Purdie
2009-01-02 12:58 ` Koen Kooi
2009-01-14 0:03 ` Robert Schuster
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=20090101220229.GH7040@smtp.west.cox.net \
--to=trini@kernel.crashing.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@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.