autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Generalize GNUmakefile, ...


From: Jim Meyering
Subject: Re: [PATCH] Generalize GNUmakefile, ...
Date: Thu, 13 Mar 2008 23:44:57 +0100

Eric Blake <address@hidden> wrote:

> [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).
> Differences between the two:

Thanks for looking into this.

> 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

If consensus is for maint.mk, I'm happy to switch to that,
assuming it's not too disruptive, otherwise.
Far better to have only one such file name.

> the gnulib version makes the existence of maint-cfg.mk (cf. Makefile.cfg)
> option, rather than required
>
> 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
>
> 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

This is one way in which the gnulib version is better.

> 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

The combination of VPATH and maintainer-related targets is important
to at least one person: Ralf ;-)

> Is it worth trying to re-merge these two approaches, since they forked
> from a common ancestor?  At this point, I'm thinking of having two

Most definitely.

> modules, one that distributes just GNUmakefile, and leaving
> maintainer-makefile to depend on the new module and just provide maint.mk.
> ~ The new module could then add the configure.ac and Makefile.am rules for
> VPATH builds.  We'd have to figure out how to choose between the names
> maint.mk vs. Makefile.maint.  And since GNUmakefile is placed in build-aux
> by gnulib-tool, each package that uses it would need to either use
> bootstrap to move it to the top-level directory, or commit a symlink in
> the top-level directory that points to where gnulib-tool will dump it in
> build-aux.  Ultimately, a tarball must have GNUmakefile in the top-level
> directory if it is going to issue the helpful reminder to run configure
> for users that have GNU make and just unpacked the tarball.

Another approach would be to version-control GNUmakefile, but to build in
a mechanism whereby it alerts us when a newer version appears in build-aux/.




reply via email to

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