diff options
| author | Pedro Alves <palves@redhat.com> | 2013-07-01 11:14:42 +0000 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2013-07-01 11:14:42 +0000 |
| commit | 3574124b5f33fb080dfe11d4a98475a991e6fb25 (patch) | |
| tree | d93b4b594f1ea61ec181d1f5fea0ea98c7329d03 /config | |
| parent | 702dc4fd25277e0b3206af531c59cea4fbf58be4 (diff) | |
| download | binutils-gdb-3574124b5f33fb080dfe11d4a98475a991e6fb25.tar.gz | |
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.
Diffstat (limited to 'config')
0 files changed, 0 insertions, 0 deletions