[Top][All Lists]
[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/.
- [PATCH] Generalize GNUmakefile, ..., Jim Meyering, 2008/03/12
- Re: [PATCH] Generalize GNUmakefile, ..., Jim Meyering, 2008/03/12
- Re: [PATCH] Generalize GNUmakefile, ..., Eric Blake, 2008/03/12
- Re: [PATCH] Generalize GNUmakefile, ..., Paul Eggert, 2008/03/13
- Re: [PATCH] Generalize GNUmakefile, ...,
Jim Meyering <=
- Re: [PATCH] Generalize GNUmakefile, ..., Eric Blake, 2008/03/20
- Re: [PATCH] Generalize GNUmakefile, ..., Eric Blake, 2008/03/20
- Re: [PATCH] Generalize GNUmakefile, ..., Jim Meyering, 2008/03/20
- Re: [PATCH] Generalize GNUmakefile, ..., Ralf Wildenhues, 2008/03/20
- Re: [PATCH] Generalize GNUmakefile, ..., Simon Josefsson, 2008/03/20