Re: [ANNOUNCEMENT] GDB 11 release branch created!

> Cc: [email protected], [email protected], [email protected],
>  [email protected]
> From: Tom de Vries <[email protected]>
> 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.