qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: more bogus meson warnings
Date: Wed, 3 Nov 2021 14:37:58 +0100	[thread overview]
Message-ID: <e5eee498-85a4-2f22-2580-9bcd6621f746@redhat.com> (raw)
In-Reply-To: <CAFEAcA9KF1437LXv+icrizZYcDiNZPn4KRMd0r7rEZWtDKxjpA@mail.gmail.com>

On 11/3/21 13:19, Peter Maydell wrote:
> This is not my experience. I find that:
>   * test in configure: configure doesn't enable the thing
>   * test in meson: meson produces a WARNING, but goes ahead anyway,
>     and then the final link fails
> 
>> So, in general, you _already_ have an improvement over what was there before.
> 
> Well, in practice what happened was that before the recent changes
> configure correctly didn't put dynamic libraries into the link line,
> and so my configure options resulted in a successful build.

That depends on the individual test.  There are three different cases:

- pkg-config without compile test: in that case you were already 
disabling everything.  You didn't see the improvement (WARN at 
configure/meson time vs. failure at build time) just because you already 
had the link failure years ago

- pkg-config with compile test: this was the case for a handful of 
libraries (spice, epoxy, virglrenderer, gnutls/nettle).  Here indeed 
it's not an improvement in your experience.  On the other hand, I don't 
see any reason to do this for 3-4 libraries out of the dozens that we test.

- library + compile test: the warning is likely not bogus

>> The warning is emitted in the case where the files are present but the
>> test program fails. Of course, Meson doesn't have a crystal ball for
>> the cc.links test when it says that the static lzo2 library is there
>> (apparently it is).
> 
> They're two tests under the hood, but they both need to pass
> for us to be able to use the feature. If they don't both pass,
> then meson should just quietly say "OK, we don't have this thing"
> (ie it could print a "Something or other: NO" line, but it should
> not be printing a "WARNING" line).

Of course it's possible to downgrade the warning line, but I'd rather 
first be sure that the warning is bogus.  If you _do_ have a header and 
static library, but somehow it cannot be used to link the test program, 
it would be correct to warn.  Unlike the configure script, Meson does 
have code to distinguish static vs shared libraries, so the compile test 
should be unnecessary; I would like to understand what causes it to 
fail, so that your system says "Library snappy found: YES" (and warns), 
whereas mine says "no".  I can check that using config-host.mak and 
meson-logs/meson-log.txt.

Paolo

> I just want meson to follow the convention that we have had for
> years, which is:
>   * if I say --enable-foo, then failing to find foo should be an
>     error
>   * if I say --disable-foo, then don't probe for foo at all
>   * if I say nothing, then probe for the various things we need to
>     enable the foo feature, and if they're not presentor not usable
>     for some reason then just quietly don't enable the foo option
> 
> I specifically do *not* want meson to print anything saying
> "WARNING" for case 3, because this should be a fairly normal
> state of affairs.



  reply	other threads:[~2021-11-03 13:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-02 13:38 more bogus meson warnings Peter Maydell
2021-11-02 13:40 ` Peter Maydell
2021-11-03  8:01 ` Paolo Bonzini
2021-11-03 12:19   ` Peter Maydell
2021-11-03 13:37     ` Paolo Bonzini [this message]
2021-11-04 11:02       ` Peter Maydell
2021-11-04 12:54         ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5eee498-85a4-2f22-2580-9bcd6621f746@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).