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.
You would have to make everything bold, and at that point you can
just omit the boldnes. 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.
In your Shattow SDK Uebertoolchain.bb you might just set
ASSUME_PROVIDED += "qemu-native" and be done, please take
a look at the bitbake manual describing this feature.
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.