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

[Daniel P . Berrangé]

On Sun, Sep 13, 2020 at 12:05:31PM +0200, Paolo Bonzini wrote:
> Right now meson_options.txt lists less than a dozen options, but about
> 40 more could come as configure tests are converted and moved to
> meson.build.  Each option needs code in configure to parse it and pass
> the option down to Meson as a -D command-line argument; in addition the
> default must be duplicated between configure and meson_options.txt.
> 
> This series tries to remove the code duplication by passing unknown
> --enable and --disable options to a Python program, and using
> Meson's introspection support to match those to meson_options.txt
> 
> The disadvantages are:
> 
> - because we parse command-line options before meson is available,
> the introspection output is stored in the source tree.  The output
> is slightly modified using the "jq" tool in order to ensure that it's
> stable and that modifications to meson_buildoptions.txt do not cause
> horrible conflicts.  This is the main reason for the unattractive
> diffstat (the number of JSON lines added is higher than the number
> of configure lines removed, though of course the latter are code
> that must be maintained manually and the former is not).
> 
> - we now need Python to generate the full help, so if Python is
> missing we can only print a partial message and direct the user
> to specify the interpreter with --python.  It would be possible to fix
> this by rewriting the script in Perl (at least on Fedora, JSON::PP is
> always installed if Perl is, because it's a dependency for CPAN; I'd
> have to check Ubuntu and the BSDs), or if we want to write it as a
> Bourne shell script, to further massage the introspection output into
> for example TAB-separated values.

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.

> 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 ?

If correct, then I'd say it probably isn't worth the hassle. 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.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|