public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

  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).