qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call for 2017-03-14


From: Juan Quintela
Subject: Re: [Qemu-devel] KVM call for 2017-03-14
Date: Tue, 14 Mar 2017 09:59:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Peter Maydell <address@hidden> wrote:
> On 14 March 2017 at 09:13, Stefan Hajnoczi <address@hidden> wrote:
>> On Mon, Mar 13, 2017 at 11:02:01AM +0100, Peter Maydell wrote:
>> The minimum requirements for the new language:
>> 1. Does it support the host operating systems that QEMU runs on?
>> 2. Does it support the host architectures that QEMU runs on?
>
> Speaking of this, I was thinking that we should introduce
> a rule that for any host OS/arch we support we must have
> a build machine so we can at least do a compile test.
> For instance if you believe configure we support Solaris
> and AIX, but I bet they're bit-rotting. The ia64 backend
> has to be a strong candidate for being dumped too.
> Demanding "system we can test on or we drop support"
> would let us more clearly see what we're actually running
> on and avoid unnecessarily ruling things out because they
> don't support Itanium or AIX...

YES, YES and YES.

I demand an osX build machine NOW!!!!  Remote access is ok.

Now more seriously, I can (relatively easy) compile test my pull
requests with:
- linux x86 (latest fedora, but I can get an older one if needed)
- linux x86_64 (latest fedor,, but the same)
- mingw64 32bit (latest fedora, but here I have the problem that Peter
  uses a different crosscompiler than me)
- mingw64 32bit (the same)

But for the rest, I need to wait that somebody told me that it breaks
the build.  Normally it is things like size_t is 32bit instead of 64bit
or some stupid things like that, that are trivial to fix if I can
compile there before doing the pull submission.

Later, Juan.



reply via email to

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