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: Yonggang Luo <luoyonggang@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PULL v2 00/22] Build system + misc changes for 2020-10-16
Date: Mon, 19 Oct 2020 10:12:10 +0200	[thread overview]
Message-ID: <1efe7775-d004-be35-706d-1b72a662bc52@redhat.com> (raw)
In-Reply-To: <CAFEAcA-HiKQ5Kj7-kJhJjzCjd80-OPhiUFUzJVJcCNo7z2w4tw@mail.gmail.com>

On 17/10/20 21:48, Peter Maydell wrote:
>> 1) are you going to pull v3 and I can fix up everything later?  Or would
>> you prefer me to send v4 once the new curses test is reviewed?
> 
> If the only issue with v3 is that stray warning message I'm
> OK with applying it and improving the test later.

Yes.

>> 2) would you prefer the "library was found but headers weren't" to warn,
>> issue an informative message, or be completely silent?
> 
> I think the build system should just say whether it found a
> working curses setup or not, and do our usual "this is fatal
> if --enable-whatever, otherwise just disable feature". If we
> happen to have convenient information to put in whatever
> the new build system's equivalent of config.log is [ie the
> saved-for-debug-purposes log], we might as well put it in,
> but we don't need to put that in the stdout. (We shouldn't
> say "ncurses found: YES" unless we actually found a working
> version, ideally.)

Ok, I think we can at least use cc.find_library(has_headers: '...') to
avoid warning for the most basic failure mode, and then use cc.links()
to further refine the check.  If the curses header is present but the
test program fails to link, then we are in the same situation as the
multipath check and warning makes sense.

Paolo



      reply	other threads:[~2020-10-19  8:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 15:53 [PULL v2 00/22] Build system + misc changes for 2020-10-16 Paolo Bonzini
2020-10-16 15:53 ` [PULL 18/22] meson: Move the detection logic for sphinx to meson Paolo Bonzini
2020-10-17 13:09 ` [PULL v2 00/22] Build system + misc changes for 2020-10-16 Peter Maydell
2020-10-17 13:22   ` Peter Maydell
2020-10-17 13:39     ` Paolo Bonzini
2020-10-17 13:38   ` Paolo Bonzini
2020-10-17 14:39     ` Peter Maydell
2020-10-17 15:37       ` Paolo Bonzini
2020-10-17 16:16         ` 罗勇刚(Yonggang Luo)
2020-10-17 16:37         ` Paolo Bonzini
2020-10-17 19:48           ` Peter Maydell
2020-10-19  8:12             ` Paolo Bonzini [this message]

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=1efe7775-d004-be35-706d-1b72a662bc52@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=luoyonggang@gmail.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).