From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] Stop on multiple providers but none explicitly specified
Date: Fri, 16 May 2008 00:25:07 +0200 [thread overview]
Message-ID: <g0id83$qie$1@ger.gmane.org> (raw)
In-Reply-To: <c384c5ea0805151350o19a22753y87545cfc9e22c7d1@mail.gmail.com>
Leon Woestenberg wrote:
> Use cases:
>
> Selecting "MACHINE=microblaze_dev_board, bitbake helloworld-image.bb"
> should work out of the box if we add the microblaze toolchain.
>
> Selecting "MACHINE=new_machine_with_new_arch DISTRO=old_distro bitbake
> some-image.bb" should as least TRY to build the image for the machine
> using the toolchain that is available in OpenEmbedded.
I've tried to make OE do "the right thing" in the past, but at the time
the ARM users were strongly divided into seperate camps, with
conflicting use cases (eg. some people insisted on hard-float, others on
soft-float).
In the end it was both easier and cleaner (no double _distro_machine
overrides in gcc_foo.bb) to specify the toolchain in the distro.
Since a few weeks the toolchain portion in angstrom is a log cleaner
since people can now use subarch overrrides (armv7a, ppc405) to base
their decision on.
From a practical POV I'd say "pick a distro that's maintained and
supports uclibc" for you microblaze board, and you should have very
little trouble getting it to work.
From a theoretical POV I'd say "OE should do the right thing", but "the
right thing" is sadly such a political minefield that makes having a
distro based with lots of technical merits (subarch overrides,
modularity, extendability, QA integration, etc) like Angstrom is a blessing.
For years OE claimed "just change the MACHINE and everything just
works", but it took angstrom nearly two years to make that a reality, so
don't underestimate the work[1] involved making everything "just work"
regards,
Koen
[1] Just look at the the sheer amount of nasty python code in angstrom
to select OABI for certain machines in a sane, supportable way....
next prev parent reply other threads:[~2008-05-16 12:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-14 21:36 [RFC] Stop on multiple providers but none explicitly specified Leon Woestenberg
2008-05-15 16:42 ` Richard Purdie
2008-05-15 18:38 ` Tom Rini
2008-05-15 18:51 ` Leon Woestenberg
2008-05-15 20:11 ` Tom Rini
2008-05-15 20:50 ` Leon Woestenberg
2008-05-15 22:06 ` Tom Rini
2008-05-15 22:25 ` Koen Kooi [this message]
2008-05-15 21:45 ` Richard Purdie
2008-05-16 21:44 ` Leon Woestenberg
2008-05-17 21:59 ` Richard Purdie
2008-05-18 22:48 ` Leon Woestenberg
2008-05-19 8:38 ` 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='g0id83$qie$1@ger.gmane.org' \
--to=k.kooi@student.utwente.nl \
--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.