tree a0c10a2fae6dd759924bc360a6e9f3f52aa77054
parent c3466dee852578e8aab15662ee60ec184d7069e1
author Andrew Burgess <aburgess@redhat.com> 1715348463 +0100
committer Andrew Burgess <aburgess@redhat.com> 1719227600 +0100

gdb/doc: don't try to copy GDBvn.texi from the source tree

The build recipe for gdb.dvi and gdb.pdf contains instructions for
copying the GDBvn.texi file from the source tree into the build
directory if the GDBvn.texi file doesn't already exist in the build
directory.

The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi,
and we have a recipe for building GDBvn.texi.

What's happening here is this:

  - In a git checkout of the source tree there is no GDBvn.texi in the
    source tree, the GDBvn.texi dependency will trigger a rebuild of
    GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf.

  - In a release tar file we do include a copy of GDBvn.texi.  This
    file will appear to be up to date, and so no copy of GDBvn.texi is
    created within the build directory.  Now when building gdb.dvi
    and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from
    the source tree into the build directory.

However, copying GDBvn.texi from the source directory is completely
unnecessary.  The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and
pass '-I $(srcdir)' as an argument, this means that texi2dvi will look
in the $(srcdir) to find included files, including GDBvn.texi.

As such I believe we can remove the code that copies GDBvn.texi from
the source tree into the build tree.

I've tested with a release build; creating a release with:

  ./src-release gdb

Then in an empty directory, unpacking the resulting .tar file,
creating a parallel build directory and doing the usual configure,
make, and 'make install'.

Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked
source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf
and dvi files, this works fine without having to either build or copy
GDBvn.texi into the build directory.

Approved-By: Tom Tromey <tom@tromey.com>