From: Tom de Vries <tdevries@suse.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de,
gdb@sourceware.org
Subject: Re: [ANNOUNCEMENT] GDB 11 release branch created!
Date: Tue, 6 Jul 2021 16:58:28 +0200 [thread overview]
Message-ID: <8731b5b6-814f-8559-d72e-b8c86e2ee6d7@suse.de> (raw)
In-Reply-To: <83czrwhj02.fsf@gnu.org>
On 7/5/21 5:34 PM, Eli Zaretskii wrote:
>> Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de,
>> gdb@sourceware.org
>> From: Tom de Vries <tdevries@suse.de>
>> Date: Mon, 5 Jul 2021 15:36:07 +0200
>>
>>> Wouldn't it be better to modify the configure script so that
>>> READLINE_TEXI_INCFLAG always includes "-I ${READLINE_DIR}"? Or did I
>>> misunderstand the reason why makeinfo doesn't find the Readline
>>> manual?
>>
>> I was not trying to suggest a fix, but merely trying to point out that
>> we seem to be going forth and back on this (that, and the reproducer
>> seemed to be worth sharing at that point).
>>
>> Anyway, by now I've investigated a bit further.
>>
>> The difficulty seems to be that the documentation is dependent on
>> configure options.
>
> Yes, and that should probably change (I have an idea for how to do
> that).
Cool.
> But the change isn't so trivial, so I think it isn't
> appropriate for the branch.
Ack.
> Therefore, I tried to propose a band-aid:
> have the readline/readline/doc directory be _always_ on the makeinfo's
> include path, so that if someone reconfigures GDB like in the
> reproducer, they still get a successful build, albeit with a couple of
> sections in the manual they don't need.
>
AFAIU, the problem is not that users get a couple of sections in the
manual they don't need. The problem is that the users get the incorrect
version of a section of the manual.
> Could you please see if my proposal solves the immediate problem? And
> if not, explain what I missed?
>
Sure, no problem.
I did this:
...
- READLINE_TEXI_INCFLAG=
+ READLINE_TEXI_INCFLAG='-I $(READLINE_DIR)'
...
in src/gdb/configure and managed to finish the build.
>> I can think of two clean ways to handle pre-generated docs in such a case:
>> - not including pre-generated docs in the source tarball
>
> That'd contradict GNU conventions: we always include the generated
> Info manuals in the release tarballs.
>
>> - generating a version of the docs for the source
>> tarball, that conservatively agrees with all configure choices.
>
> I think this is sufficiently complex to avoid doing that on the
> branch. We could try this on master, of course. But right now, I'd
> like to fix the branch so that we don't have a regression, while still
> allowing people to build GDB without having Texinfo installed.
>
>> To give an example of what I'm concerned about: say a user has a system
>> without makeinfo, and builds with --with-system-readline. Then the gdb
>> documentation point to the in-source readline docs, which does not
>> necessarily agree with the actually used readline version.
>
> That's true, but I don't see that as a serious enough problem to delay
> the release of GDB 11. Of course, it isn't my call, eventually.
>
Well, I don't see any reason to delay the release.
I'd say the easiest way to fix the problem is to revert the commit that
introduced the problem.
Thanks,
- Tom
next prev parent reply other threads:[~2021-07-06 14:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 17:52 Joel Brobecker
2021-07-04 9:06 ` Andreas Schwab
2021-07-05 10:36 ` Tom de Vries
2021-07-05 12:33 ` Eli Zaretskii
2021-07-05 13:36 ` Tom de Vries
2021-07-05 15:34 ` Eli Zaretskii
2021-07-06 14:58 ` Tom de Vries [this message]
2021-07-06 15:50 ` Eli Zaretskii
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=8731b5b6-814f-8559-d72e-b8c86e2ee6d7@suse.de \
--to=tdevries@suse.de \
--cc=bernd.edlinger@hotmail.de \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
--cc=tom@tromey.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).