Eric Blake <[EMAIL PROTECTED]> writes: > [adding gnulib] > > According to Jim Meyering on 3/12/2008 5:39 AM: > | Hi, > > Hi Jim, Simon, others, > > | > | I'm planing to make the following change in coreutils > | so that autoconf can then use the exact same GNUmakefile. > > Hmm. I was about to try to add the latest coreutils/autoconf/m4 > GNUmakefile to gnulib, to make it easier to share. But gnulib already > provides build-aux/GNUmakefile as part of the maintainer-makefile module, > added by Simon a while ago (and originally borrowed from coreutils).
Hi! Thanks for looking into this, and sorry for slow response. Merging them would be useful. There are some things in coreutils that I'd like to have, but haven't had time to merge into gnulib. > Differences between the two: > > the gnulib version uses maint.mk rather than Makefile.maint as its file of > maintainer-specific rules, and includes maint.mk as part of the module The reason was that my emacs appear to treat *.mk as makefiles, but didn't with *.maint. I don't care strongly, but do prefer maint.mk. > the gnulib version makes the existence of maint-cfg.mk (cf. Makefile.cfg) > option, rather than required I don't care strongly about this. The name 'maint-cfg.mk' haven't been the best though, since it clashes with name completion of main.mk. Is cfg.mk too generic? I think this would be a good opportunity to change the name. > the coreutils version uses build-aux/git-version-gen to form nice > intra-release version numbering, while minimizing when a full autoreconf > must be performed to pick up the latest version number This is one thing I'd like to have in my packages as well. > the gnulib version uses '.DEFAULT_GOAL:=' rather than 'all:' when Makefile > is not present to trigger the error message about needing to run configure > in all cases, rather than just a few I don't care strongly, but this approach allows maint-cfg.mk to override the default goal. I use this in all of my projects to invoke autoreconf etc if they haven't been invoked yet. (I don't use the bootstrap approach since, as far as I can tell, it makes it difficult to prepare security releases that are bit-by-bit identical with the earlier release, except for the patch to fix the security problem.) > the coreutils version conditionally uses AC_CONFIG_LINKS in configure.ac, > along with EXTRA_DIST and distclean-local in Makefile.am, to support > GNUmakefile usage even in VPATH builds I can't comment on that, but if it doesn't cause problems for me, I'm for it. :) > Is it worth trying to re-merge these two approaches, since they forked > from a common ancestor? Yes please. > At this point, I'm thinking of having two modules, one that > distributes just GNUmakefile, and leaving maintainer-makefile to > depend on the new module and just provide maint.mk. The GNUmakefile seems rather small, but if you think separating the modules gives an advantage, I don't object. There needs to be some hooks in GNUmakefile to load the maintainer-makefile though, I think. Bruno Haible <[EMAIL PROTECTED]> writes: > But since a GNUmakefile in the top directory of gnulib would hide the Makefile > of gnulib, I propose to move it from build-aux/GNUmakefile to top/GNUmakefile, > and enhance gnulib-tool with a filename rewriting rule that transforms > $GNULIBDIR/top/GNUmakefile --> $PACKAGEDIR/GNUmakefile I think this is a good idea. /Simon
