Re: [RFC PATCH 0/3] Automatically convert configure options to meson build options

[Paolo Bonzini]

On 14/09/20 11:12, Daniel P. Berrangé wrote:
> IMHO we should stay as far away from Perl as possible, and I say this as
> someone who enjoys writing Perl scripts !  Perl is a significant barrier
> to entry for potential contributors, because it just doesn't have the
> wide knowledge base that it did in the past. You can expect most people
> to have some familiarity with Python, or be able to pick it up fairly
> easily in a way that just isn't possible in Perl.
> 
> As for shell, we have a never ending stream of bugs due to the wide
> range of different shell impls which make portable coding very hard.
> 
> In general I think our overall goal should be to focus on getting down to
> use of a single scripting language in QEMU, and that language clearly has
> to be python3. We shouldn't introduce any new usage of Perl or Shell
> in QEMU IMHO. Even if we think the usage will only be short term temporary
> workaround, short term hacks in QEMU have a habit of living for years longer
> than we expect.

I totally agree.  This would not be a short term workaround, I expect it
to stay for years; I don't expect the transition of the configure script
to Meson to be very short.

This can be both a pro and a con.  On one hand it means this is "more
magic" that is here to stay.  On the other hand it makes transition
patches smaller and easier to review.

I agree that in principle all scripting should be Python.  On the other
hand Perl is quite suitable for "configure tasks that are too
complicated for shell" and are not going to be rewritten in Meson down
the road.  And I say that as someone who has written exactly 3 serious
Perl programs in his life, two of which are part of QEMU. :)

In this case shell scripting could also be a plausible alternative; I
didn't try only because I first tried the obvious choice of Python.

Or we can just decide that an incomplete help below a "please use
--python" error is good enough.

>> Opinions are welcome on whether this is worthwhile and how to solve
>> the above doubts.
> 
> IIUC, the motivation of this series is just to remove some duplication
> of defaults / args, nothing more than that ?

Yes, though it's quite some duplication: right now an option needs

- a default in configure

- command line parsing in configure

- a Meson -D argument in configure

- an help message in configure

- a declaration (including default and help) in meson_options.txt

so this patch reduces an option from 8-9 lines to 2.

There are a couple secondary goals too.  First, making sure all the
policy is in meson_options.txt and not configure; this avoids surprises
when/if we can start invoking meson directly.  Second, removing
variables completely from the configure script gives a better idea of
interdependencies between the configure tests.

Thanks,

Paolo

> I'd say we should focus effort on just converting more of configure
> to meson, as quickly as practical, and not try to add much more magic
> that's only relevant for the transition time.