[Top][All Lists]

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

Re: [PATCH] Generalize GNUmakefile, ...

From: Simon Josefsson
Subject: Re: [PATCH] Generalize GNUmakefile, ...
Date: Thu, 20 Mar 2008 11:23:18 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

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 rather than Makefile.maint as its file of
> maintainer-specific rules, and includes 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

> the gnulib version makes the existence of (cf. Makefile.cfg)
> option, rather than required

I don't care strongly about this.  The name '' haven't been
the best though, since it clashes with name completion of  Is 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 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,
> along with EXTRA_DIST and distclean-local in, 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

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.


reply via email to

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