Wed 20 Sep 2006 09:31:11 PM UTC, comment #10:
OK, I installed the attached patch to add a --force option
to bootstrap along the lines you suggested.
|
Wed 20 Sep 2006 05:25:16 PM UTC, comment #9:
My concern is that running "bootstrap" not be done lightly.
If you don't want to disable it entirely, when run from a non-version-controlled directory, a compromise would be to
require a --force option in that case.
Otherwise, we may well end up getting problem reports that claim
to be using coreutils-6.3, when in fact they're using newer files
that a post-release ./bootstrap pulled from gnulib.
|
Wed 20 Sep 2006 05:05:05 PM UTC, comment #8:
"bootstrap" already should "just work" even when it's run in a directory that has already been bootstrapped, or a directory that came from a tarball. I don't offhand see why we'd want to disable that capability.
|
Wed 20 Sep 2006 01:38:58 PM UTC, comment #7:
Including bootstrap in the tarball sounds like a good idea, but
perhaps with a new snippet of code to make it fail when it's run
from a directory that appears to have been untarred, rather than
checked out from some version control system. Then, upon failure,
it could provide instructions and/or justification.
|
Mon 18 Sep 2006 11:43:43 PM UTC, comment #6:
If it serves as any reference point, M4 1.4.6 includes its bootstrap in its tarball. Someone using the tarball is expected to neither run bootstrap nor to run autoreconf (a fact that automake checks during 'make distcheck'), but the files are still shipped should they choose to rather than forcing them to check m4 out from CVS, similar to how configure.ac or Makefile.am is included in the tarball. On the other hand, running bootstrap implies that you have checked out gnulib from CVS, so omitting bootstrap from the tarball isn't too severe because by the time a user has grabbed gnulib from CVS, they can go all the way grab the bootstrap script and rest of the package from CVS as well.
As to the original report, running autoreconf on a package without first checking whether it works without modifications is risky. The fact that it triggered a failure here should not come as a surprise, because it is not recommended practice; indeed, coreutils 6.2 depends on files that are newer than what gettext 0.15 provides, but gettext 0.15.1 has not yet been released, so autoreconf alone is helpless to do the job correctly. But maybe there is a bug report against gettext here, for the fact that autopoint blindly replaces macros to older versions rather than trusting that a newer version of the macro does not need to be downgraded to what that macro used to be at the time of the gettext release.
|
Mon 18 Sep 2006 10:51:56 PM UTC, comment #5:
You can get bootstrap from
http://cvs.savannah.gnu.org/viewcvs/coreutils/bootstrap?rev=1.15&root=coreutils&view=log
I'm not sure whether it should be included as part of the tarball. It isn't intended for ordinary builder use, but on the other hand the maintainers use it a lot. Perhaps Jim has an opinion. In the meantime I'll reopen the bug.
|
Mon 18 Sep 2006 07:58:17 PM UTC, comment #4:
There is no bootstrap.
|
Mon 18 Sep 2006 07:12:10 PM UTC, comment #3:
Ah, sorry, I misread the example. I guess the right answer is
that coreutils isn't set up to use autoreconf. You can use
"bootstrap" instead; it gets the pieces that autoreconf would
get, but omits stuff like the "lock" module that autoreconf
mistakenly would include.
|
Mon 18 Sep 2006 05:45:07 PM UTC, comment #2:
There is no gnulib involved.
|
Mon 18 Sep 2006 05:42:12 PM UTC, comment #1:
I think that was a gnulib-tool bug, fixed by my recent change
to gnulib-tool (revision 1.167, dated 2006-09-18 10:03:47 -0700).
Please upgrade gnulib and try again.
|
Mon 18 Sep 2006 03:29:19 PM UTC, original submission:
$ cd coreutils-6.2
$ autoreconf -fi
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/glibc21.m4
Copying file m4/iconv.m4
Copying file m4/intdiv0.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-h.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lcmessage.m4
Copying file m4/lib-ld.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/progtest.m4
Copying file m4/signed.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/uintmax_t.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
configure.ac:38: warning: gl_LOCK_EARLY is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:30: gl_EARLY is expanded from...
configure.ac:38: the top level
configure.ac:38: warning: gl_LOCK_EARLY is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:30: gl_EARLY is expanded from...
configure.ac:38: the top level
configure.ac:38: warning: gl_LOCK_EARLY is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:30: gl_EARLY is expanded from...
configure.ac:38: the top level
configure:5353: error: possibly undefined macro: gl_LOCK_EARLY
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
|