qemu-devel
[Top][All Lists]
Advanced

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

Re: [DRAFT PATCH 000/143] Meson integration for 5.2


From: Markus Armbruster
Subject: Re: [DRAFT PATCH 000/143] Meson integration for 5.2
Date: Fri, 07 Aug 2020 15:55:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 07/08/20 09:56, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>>> This the more or less final version of the Meson conversion.  Due to
>>> the sheer size of the series you have been CCed only on the cover
>>> letter.
>> 
>> Perfect timing: right before I drop off for two weeks of vacation.  I'm
>> excused!  *Maniacal laughter*
>> 
>> Have you run it through our CI?
>
> Of course not. O:-)
>
>> without even more weeks of intense rebasing.
>
> FWIW there were only three hard rebases from 5.0 to 5.2:
> qemu-storage-daemon (by far the hardest), linux-user's syscall_nr.h
> generation, and fuzzing (easiest except it required conversion of qtest).  S
>
> I would like to merge this on August 21st.  I hope to post a
> "definitive" verion on August 14th, and hope to work with Peter the next
> week on getting it to pass his tests.

Sounds good to me.

>                                        Perhaps that's optimistic though.

If it's not ready then, we pick another date and try again.

> Depending on when it's ready, I can pick up the series that gets rid of
> Texinfo, if Peter and yourself don't want to learn Meson just for that.

I appreciate the offer.  I figure I'll eventually have to learn some
Meson anyway.  Still, having to learn it *now* to unblock that series
may be inconvenient.

> Anyway, I think this is the no-return point: if people say no, I'm not
> going to push it any further.  If people say yes, we'd better merge it
> quickly and be done with it.
>
> I do understand resistance.  It's a new tool replacing a 40-year-old
> standard; build systems are not fancy; and there is a substantial sunken
> cost.  All I can answer is that the line between sunken cost and
> Stockholm syndrome is a fine one.  I cannot say this stuff has been
> *fun*, but at least the debugging was refreshing compared to Makefiles.
>  Again not a very high bar, but it's something.

I'm willing to trust your judgement on this one.

I'm notoriously conservative in my choice of tools, and GNU Make is a
much better tool than some people give it credit for, but I've long felt
we've pushed it beyond its limits.

[...]




reply via email to

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