From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 9/9] populate_sdk_ext: add extensible SDK
Date: Mon, 23 Feb 2015 18:06:18 +0000 [thread overview]
Message-ID: <1424714778.26813.1.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAP9ODKp4QG0iSUzUU8ZaAkKjsg34zo8FwHiXZkD-XoA_su1hpA@mail.gmail.com>
On Mon, 2015-02-23 at 15:00 -0300, Otavio Salvador wrote:
> On Mon, Feb 23, 2015 at 2:54 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Monday 23 February 2015 14:41:34 Otavio Salvador wrote:
> >> On Mon, Feb 23, 2015 at 2:00 PM, Paul Eggleton
> >> <paul.eggleton@linux.intel.com> wrote:
> >> > From: Randy Witt <randy.e.witt@linux.intel.com>
> >> >
> >> > This bbclass will create an SDK with a copy of bitbake and the metadata
> >> > and sstate for the target specified for the task. The idea is to let
> >> > "system" developers both work on applications and then test adding them
> >> > to an image without having to switch between workspaces or having to
> >> > download separate items.
> >> >
> >> > Rather than running bitbake directly however, the primary way of running
> >> > builds within the extensible SDK is to use the "devtool" command. The
> >> > rest of the build system is fixed via locked shared state signatures,
> >> > and thus only the recipes you have added get built.
> >> >
> >> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> >> > Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
> >> > Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> >>
> >> Why another class? it could be tuned using SDKIMAGE_FEATURES
> >
> > If you look at what the class does it would be a bit messy to do it that way -
> > I wanted to get something working with minimal impact. I don't doubt
> > that it could be implemented as an SDKIMAGE_FEATURES item though
> > with extra work.
>
> As far this does not gets merged I am fine with that. This is clearly
> a WIP code and shouldn't be merged as is.
This code adds in an alternative SDK format and it drives that using a
different task target. Right now its hard for people to see where things
are going, this puts it in easy reach whilst allowing the current SDK to
continue to work too.
I think a choice of two different task targets here makes sense to drive
this configuration rather than SDKIMAGE_FEATURES and I agree with Paul
that adding it the other way would be complex, error prone and
confusing.
Cheers,
Richard
next prev parent reply other threads:[~2015-02-23 18:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 17:00 [PATCH 0/9] Extensible SDK Paul Eggleton
2015-02-23 17:00 ` [PATCH 1/9] gen-lockedsig-cache: Allow cross-filesystem copies Paul Eggleton
2015-02-23 17:00 ` [PATCH 2/9] sstatesig: Add ability to filter list of tasks for locked-sigs.inc Paul Eggleton
2015-02-23 17:00 ` [PATCH 3/9] copy_buildsystem.py: Add a way to copy buildsystem to a directory Paul Eggleton
2015-02-23 17:00 ` [PATCH 4/9] copy_buildsystem.py: Add methods to copy shared state Paul Eggleton
2015-02-23 17:00 ` [PATCH 5/9] toolchain-scripts: Add parameters to toolchain_create_sdk_env_script Paul Eggleton
2015-02-23 17:00 ` [PATCH 6/9] toolchain-shar-template.sh: Make relocation optional Paul Eggleton
2015-02-23 17:00 ` [PATCH 7/9] uninative-tarball: Actually use bzip2 for compression Paul Eggleton
2015-02-23 17:00 ` [PATCH 8/9] scripts/oe-buildenv-internal: add means of skipping SDK check during setup Paul Eggleton
2015-02-23 17:00 ` [PATCH 9/9] populate_sdk_ext: add extensible SDK Paul Eggleton
2015-02-23 17:41 ` Otavio Salvador
2015-02-23 17:54 ` Paul Eggleton
2015-02-23 18:00 ` Otavio Salvador
2015-02-23 18:06 ` Richard Purdie [this message]
2015-02-23 18:11 ` Otavio Salvador
2015-02-23 18:29 ` Paul Eggleton
2015-02-23 22:33 ` 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=1424714778.26813.1.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
--cc=paul.eggleton@linux.intel.com \
/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