autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Generalize GNUmakefile, ...


From: Eric Blake
Subject: Re: [PATCH] Generalize GNUmakefile, ...
Date: Wed, 12 Mar 2008 21:46:31 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[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:

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 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

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


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
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.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfYo5YACgkQ84KuGfSFAYBmvACgisklluWTsj8Z0KDqSkzF0koN
R8oAn0PiWBaQuXssfXHd94JNyPDnZjBb
=g2MD
-----END PGP SIGNATURE-----




reply via email to

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