bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Who's the upstream owner of GNUmakefile?


From: Eric Blake
Subject: Re: Who's the upstream owner of GNUmakefile?
Date: Tue, 4 Aug 2020 10:18:25 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]