Reimport gnulib from scratch.
authorPedro Alves <palves@redhat.com>
Mon, 1 Jul 2013 11:14:42 +0000 (11:14 +0000)
committerPedro Alves <palves@redhat.com>
Mon, 1 Jul 2013 11:14:42 +0000 (11:14 +0000)
commit3574124b5f33fb080dfe11d4a98475a991e6fb25
treed93b4b594f1ea61ec181d1f5fea0ea98c7329d03
parent702dc4fd25277e0b3206af531c59cea4fbf58be4
Reimport gnulib from scratch.

Moving aside gnulib/import/, and re-running our
gnulib/update-gnulib.sh script, surprisingly, one gets a different
result compared to what's in the tree.  This is with pristine FSF
autoconf and FSF automake, at the versions required by
update-gnulib.sh.  However, if one just runs the update-gnulib.sh
scripts against the _existing_ tree, then nothing changes...  I
suspect gnulib-tool's merge logic might be preserving some things by
design.  This gets rid of cruft that might have accumulated over
gnulib updates.  onceonly.m4 seems to fit in that category.

gdb/
2013-07-01  Pedro Alves  <palves@redhat.com>

Reimport gnulib from scratch.
* gnulib/Makefile.in (aclocal_m4_deps): Remove reference to
import/m4/onceonly.m4.
* gnulib/aclocal.m4: Renegerate.
* gnulib/config.in: Renegerate.
* gnulib/configure: Renegerate.
* gnulib/import/Makefile.in: Renegerate.
* gnulib/import/extra/update-copyright: Renegerate.
* gnulib/import/m4/onceonly.m4: Delete.
gdb/ChangeLog
gdb/gnulib/Makefile.in
gdb/gnulib/aclocal.m4
gdb/gnulib/config.in
gdb/gnulib/configure
gdb/gnulib/import/Makefile.in
gdb/gnulib/import/m4/onceonly.m4 [deleted file]