public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tom de Vries <tdevries@suse.de>
Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de,
	gdb@sourceware.org
Subject: Re: [ANNOUNCEMENT] GDB 11 release branch created!
Date: Mon, 05 Jul 2021 18:34:37 +0300	[thread overview]
Message-ID: <83czrwhj02.fsf@gnu.org> (raw)
In-Reply-To: <b45286ef-5716-7cba-d924-43259c49616b@suse.de> (message from Tom de Vries on Mon, 5 Jul 2021 15:36:07 +0200)

> 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).  But the change isn't so trivial, so I think it isn't
appropriate for the branch.  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.

Could you please see if my proposal solves the immediate problem?  And
if not, explain what I missed?

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

  reply	other threads:[~2021-07-05 15:34 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 [this message]
2021-07-06 14:58           ` Tom de Vries
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=83czrwhj02.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=bernd.edlinger@hotmail.de \
    --cc=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=tdevries@suse.de \
    --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).