Am 14.03.2006 um 05:49 schrieb Eric Shattow:

> I would like to weigh in my opinion here

noted

> , that 'qemu-native' has no
> place being in the OE tree if it's not considered a supported (read
> "integral") part of the toolchain.

What is a toolchain? What does supported mean? I don't get your
point. I think I agree that qemu should not be installed into tmp/cross/bin.
If that is the case it is clearly a bug. Please file a bug report if this is
the case.

> Having a working 'qemu' is a
> property of the build host *nix distro, or the user/developer, since
> it is not a library dependency and only needs to be run-time
> functional. If you want to argue for 'qemu' as a regular package in
> OE, I could see that happening... though it would be a tough case to
> make for keeping it maintained.

why is maintaining it harder than any other package? Anyway as
you might have seen, we have plenty of -native packages. Why?
Well, different versions have different bugs, different distro introduce
other bugs and our buildable software has special requirement on
these native packages. e.g. to really use the ARM platform emulation
for OE you will need the CVS version of qemu. I think SuSE 8.3 does
not ship that, but OE is just buildable fine on this distribution... Anyway
besides basic requirements to perl,python,patch (anyway see bitbake.conf)
we have no special requirements on the host system, and we should
keep that.


> IMO we should be checking for the existence of qemu on the host and
> only enabling its usage if an OPT-IN flag is set. Also, this OPT-IN
> flag should be very clearly labelled and documented in big bold
> letters. Neon flashing lights optional.

Apart from the fact that it already *is* opt-in, you would have to make everything bold, and at that point you can
just omit the boldness. I agree that this should be documented in the
reference documentation.
You miss the point that we don't do any checking on the host system,
so just adding a qemu check won't work. And it contradicts the
philosophy of OE.


> If we do require qemu, then there should be someone building a
> statically linked qemu binary for all major build platforms, and
> keeping that up at OE.


How many built software did you see OE distribute? I have seen none
and I would like to keep that.
Our 'job' is to create working, best in class, high quality meta data to
let people do theirs tasks with OE.
This means if Microsoft decides that qemu is part of their deployment
they will just set ASSUME_PROVIDED.

Anyway you should recognize that OE is more than a tool to build
YOUR toolchain. e.g. it is used to build and test software on
pre existing toolchains.