From: Phil Blundell <philb@gnu.org>
To: openembedded-devel@lists.openembedded.org
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
Paul Menzel <paulepanter@users.sourceforge.net>
Subject: Re: Populating meta-oe with new patches on oe.dev
Date: Thu, 28 Jul 2011 10:37:40 +0100 [thread overview]
Message-ID: <1311845860.30326.417.camel@phil-desktop> (raw)
In-Reply-To: <201107261811.16319.paul.eggleton@linux.intel.com>
On Tue, 2011-07-26 at 18:11 +0100, Paul Eggleton wrote:
> On Sunday 17 July 2011 17:12:51 Paul Menzel wrote:
> > 3. I find the `recipe-*section*/` directories difficult to handle to
> > finding a recipe. Before I would use `recipe/` and then tab completion
> > and now I have to search for it. Are others uncomfortable with this?
>
> I'm used to it now but it did feel a bit strange to begin with.
I've been using oe-core for a while now and I do still find it a bit
annoying when you have to search in multiple directories to try to find
the recipe that you're looking for. In some cases it's obvious and
there's no problem (eg it's fairly easy to guess that gcc would be in
devtools) but the split between some of the other directories
(particularly -core/-support/-extended/-connectivity and
-graphics/-gnome/-sato) often seems a bit arbitrary.
However, emacs seems to be able to do tab completion across multiple
levels of hierarchy nowadays, so I can just type
"meta/recipes-/net-tools<TAB>" and it automatically figures out that
recipes-extended is the right thing. So in practice this is not too big
a deal for me most of the time. And I agree that having a single
massive directory of recipes is not such a great thing either, so the
current arrangement probably is a reasonable compromise.
> > 4. What images are available in/for oe-core/meta-openembedded? I liked
> > for example `minimal{,-uclibc}`? `find . -name minimal*` in `oe-core` or
> > `meta-oe` did not give any result. Not to mention the images for
> > BeagleBoard or `micro-image` for the recently sent patches for payload
> > creation for coreboot
micro-image itself doesn't currently exist for the oe-core world.
However, micro-base-image (which always seemed the more useful one) is
in the meta-micro layer, see:
http://cgit.openembedded.org/cgit.cgi/meta-micro/tree/recipes/images
If you wanted to submit a patch to reinstate micro-image, with a
suitable rationale for why it's useful, then that would be welcome.
p.
prev parent reply other threads:[~2011-07-28 9:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-15 21:42 Populating meta-oe with new patches on oe.dev Khem Raj
2011-07-16 13:25 ` [oe] " Russell Morris
2011-07-16 13:25 ` Russell Morris
2011-07-26 17:20 ` [oe] " Paul Eggleton
2011-07-26 17:20 ` Paul Eggleton
2011-07-17 16:12 ` Paul Menzel
2011-07-26 17:11 ` Paul Eggleton
2011-07-28 9:37 ` Phil Blundell [this message]
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=1311845860.30326.417.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=paulepanter@users.sourceforge.net \
--cc=richard.purdie@linuxfoundation.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.