qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: User mode linux for Mac OS X with qemu


From: François Revol
Subject: Re: [Qemu-devel] Re: User mode linux for Mac OS X with qemu
Date: Sun, 07 Jun 2009 22:13:26 +0200 CEST

> Paul Brook wrote:
> >
> > Doing cross emulation is in theory possible, however in practice it
> > gets
> > extremely messy for anything other than the trivial case and it's
> > unclear
> > whether it's worth the effort, or whether qemu is the appropriate
> > place to do
> > this (c.f. WINE).
> >
> One application of it is using Linux/Q instead of wine and java.
>
>
> Another application (my dream) is deterministic build system.
> Community
> yell loudly when OpenOffice fails to render 1:1 document from
> Microsoft
> Office.
>
> However, it is often unnoticed that it's insanely hard to do 1:1
> build
> of any randomly picked "open source" build.
>
> Pain starts from the very beginning: configure. It requires a prefix
> as
> part of its operation. Strange enough that it doesn't ask for command
> line parameters or program launch date or whatever else parameter
> unknown prior to the moment of execution.
> Compilers also like putting filenames (including pathes) into
> binaries.
> Autoconf, m4, pkg-config, lots of tools that make build result
> dependent
> on host configuration.

Well, it's just a design hole in Unices, their FOSS clones (which
failed to improve on their parent there), and the app writers.

Some other OSes have a clean API to find directories... like...
find_directory() on BeOS and Haiku (quite imaginative name), and other
API to load resources from the app's own binary to avoid scattering
files everywhere...
And of course dynamically locating the base app directory to find
related files at launch time...

FreeDesktop.org tried to standardize something alike for Free desktop
OSes but I don't know where it went.

But this has nothing to do with qemu or virtualization, and there is no
need to use a VM just for this as an excuse for lack of design :p

Autocrap indeed fails at many of the points it's trying to address, but
often mostly due to its users, not by itself.
Like, who ever thinks about putting AC_CHECK_LIB(m,sqrt) in
configure.ac ?
Yet it's really painful when porting something to BeOS or Haiku to have
to remove hardcoded -lm everywhere which ought to be probed by
autotools.

Maybe autocrap alternatives like CMake or Scons do this better ? I've
yet to try those.

> Every factor commits to denying the fourth freedom, freedom to
> improve.
> Anybody willing to fix the problem feels like an elephant in a
> crockery
> shop. One can never be sure that he hasn't forgot some essential
> compiler flag if he can't verify it. Ability to build 1:1 is the
> ultimate verify. If I can build original program 1:1, I can be pretty
> sure that my fix will be the only change I've maid to the compiled
> program.

Feel free to try Haiku apps :p

François.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]