On 8/4/20 10:07 AM, Eric Blake wrote:
On 8/4/20 9:58 AM, Zack Weinberg wrote:
I just pushed a commit that partially reverts a `make fetch'.
Partially revert e54e3f90: restore use of $(MAKE) in error message.
In commit 14d58bfd, the error message printed by the
‘abort-due-to-no-makefile’ rule in GNUmakefile was changed to
refer to
the value of ‘$(MAKE)’ instead of a literal ‘make’. A subsequent
‘make fetch’ (e54e3f90) clobbered this. Put it back.
Clearly we need to send the change to this error message upstream, but
I don't know who the upstream for this file is.
GNUmakefile comes from gnulib (the gnumakefile module). It is one of
the few files that has to be checked in to git rather than populated
after bootstrap; which means that every time you update to a newer
version of gnulib that happens to modify the file, it results in another
checkin of GNUmakefile in autoconf. That's what 'make fetch' is
intended to do. So, if you want a change to stick in that file, update
the gnulib version first, then update autoconf to the newer version of
gnulib containing that fix.
Sorry, I'm confusing projects. Many projects have a bootstrap script
from gnulib, and run gnulib-tool on initial checkout rather than storing
gnulib artifacts in the project repo, in such projects, it is bootstrap,
and not GNUmakefile, that must be checked into the repo. But autoconf
does not use enough files from gnulib to currently make it worth using
gnulib-tool on the fly; instead, it stores ALL files copied from gnulib
directly into the autoconf.git during 'make fetch'. But the point
remains, if you want a change to stick into a file that autoconf copied
from gnulib, then make the change in gnulib first.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
