Re: [PATCH] Generalize GNUmakefile, ...

[Simon Josefsson]

Eric Blake <address@hidden> 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 <address@hidden> 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