From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Marc-André Lureau" <mlureau@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PULL v2 000/180] QAPI patches for 2017-01-16
Date: Tue, 17 Jan 2017 14:24:53 +0100 [thread overview]
Message-ID: <874m0x7ra2.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA8vRw=13Lj_98A+3NovSeTg6e0xBopdz9EcdEeUMjjZow@mail.gmail.com> (Peter Maydell's message of "Tue, 17 Jan 2017 12:24:25 +0000")
Peter Maydell <peter.maydell@linaro.org> writes:
> On 17 January 2017 at 12:08, Markus Armbruster <armbru@redhat.com> wrote:
>> Right now, that'll make no difference whatsoever, because the programs
>> that choke on -D generate no output for the commands using the variable
>> defined with -D. All they do is gripe.
>>
>> Three possible solutions, in increasing order of complexity:
>>
>> 1. Live with the warning from old versions. If a new version comes
>> around that does something with @subtitle, it'll just work.
>>
>> 2. Suppress the warning with @iftex-hammer. No change in output now.
>> If a new version comes around that does something with @subtitle, we
>> won't profit unless we take out the @iftex.
>>
>> 3. Replace -D by @set, either by preprocessing .texi, or by including a
>> generated snippet. No change in output now. If a new version comes
>> around that does something with @subtitle, it'll just work.
>>
>> My order of preference is aligned with decreasing complexity, i.e. first
>> 1., then 2., then 3.
>>
>> Please tell me what you want.
>>
>> If you want 3., I can certainly live with it, but I'd rather do 1. or
>> 2. now, to get my rather conflict-prone pull request in, then do 3. as a
>> follow-up patch.
>
> Yeah, I think it's reasonable to apply this now and then
> fix up the warnings afterwards, since they don't break the
> build. I'll do that.
Thanks!
> In terms of what I'd like for the VERSION issue:
>
> (1) if it doesn't actually cause a change in the output, we
> should either just delete the use of VERSION entirely, or move
> it to somewhere outside of @subtitle which does actually
> appear somewhere. There's no point in putting in the version
> info if it doesn't get into the final output, whether
> it generates a warning or not.
It does affect PDF output. PDF is generated by texi2pdf, which uses
different command line options, and setting VERSION works fine there.
> (2) If we want to display VERSION then we need to use @set,
> it looks like.
We need to decide whether we want to display the information that is now
in @subtitle in makeinfo output in addition to PDF output. If yes, we
need to put it somewhere else than the subtitle, and find a
bug-compatible way to set VERSION. If no, we still might want to
silence the warning produced by old versions of makeinfo.
next prev parent reply other threads:[~2017-01-17 13:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 9:33 [Qemu-devel] [PULL v2 000/180] QAPI patches for 2017-01-16 Markus Armbruster
2017-01-16 15:58 ` Peter Maydell
2017-01-17 8:31 ` Markus Armbruster
2017-01-17 9:54 ` Marc-André Lureau
2017-01-17 10:13 ` Markus Armbruster
2017-01-17 11:08 ` Peter Maydell
2017-01-17 12:08 ` Markus Armbruster
2017-01-17 12:24 ` Peter Maydell
2017-01-17 13:24 ` Markus Armbruster [this message]
2017-01-17 13:59 ` Peter Maydell
2017-01-17 14:15 ` Marc-André Lureau
2017-01-17 14:23 ` Markus Armbruster
2017-01-17 16:43 ` Peter Maydell
2017-01-20 14:39 ` Peter Maydell
2017-01-20 15:46 ` Markus Armbruster
2017-01-20 15:48 ` Peter Maydell
2017-01-23 12:48 ` Alex Bennée
2017-01-23 13:59 ` Daniel P. Berrange
2017-01-23 14:49 ` Markus Armbruster
2017-01-24 9:53 ` Markus Armbruster
2017-01-24 10:03 ` Peter Maydell
2017-01-24 11:08 ` Markus Armbruster
2017-01-24 10:09 ` Markus Armbruster
2017-01-24 10:49 ` Paolo Bonzini
2017-01-17 17:05 ` Eric Blake
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=874m0x7ra2.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=mlureau@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.