[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
maint.mk questions
From: |
Eric Blake |
Subject: |
maint.mk questions |
Date: |
Fri, 24 Apr 2009 16:21:09 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
I'm considering switching m4 to use the maintainer-makefile module, and noticed
some improvements that we should consider. I ran 'diff -u
{m4,gnulib/top}/maint.mk' and came up with these:
Since the announcement rule already uses $(gpg_key_ID), maint.mk is assuming
that cfg.mk provided it. Therefore, M4 uses it to also ensure that the correct
key is used when tagging a release:
-VC-tag = git tag -s -m '$(VERSION)' -u $(gpg_key_ID)
+VC-tag = git tag -s -m '$(VERSION)'
For a VPATH build, news-date-check needs to reference $(srcdir)/NEWS, rather
than plain NEWS. There may be other sc_ checks broken in a VPATH build, but I
spotted this one quickly in the diff:
-news-date-check: NEWS version-check
+news-date-check: NEWS
today=`date +%Y-%m-%d`; \
- if head $(srcdir)/NEWS | grep '^\*.* $(VERSION_REGEXP) ('$$today')' \
+ if head NEWS | grep '^\*.* $(VERSION_REGEXP) ('$$today')' \
Likewise for vc-diff-check:
vc-diff-check:
- (CDPATH=; cd $(srcdir) && $(VC) diff) > vc-diffs || :
+ $(VC) diff > vc-diffs || :
There are still some coreutils-specific things, like:
+# Note that neither the binary, ginstall, nor the ].1 man page is installed.
+define my-instcheck
+ $(MAKE) prefix=$(pfx) install \
+ && test ! -f $(pfx)/bin/ginstall \
but which probably don't hurt other packages.
Another VPATH fix:
announcement: NEWS ChangeLog $(rel-files)
- @$(srcdir)/build-aux/announce-gen \
+ @./build-aux/announce-gen \
--release-type=$(RELEASE_TYPE) \
--package=$(PACKAGE) \
--prev=$(PREV_VERSION) \
--curr=$(VERSION) \
--gpg-key-id=$(gpg_key_ID) \
- --news=$(srcdir)/NEWS \
- --bootstrap-tools=autoconf,automake,gnulib \
+ --news=NEWS \
+ --bootstrap-tools=autoconf,automake,bison,gnulib \
Oh, and the --bootstrap-tools had better be something specified by cfg.mk, as
m4 does not want bison in the list.
+# Use mv, if you don't have/want move-if-change.
+move_if_change ?= move-if-change
Should the maintainer-makefile module ensure that gnulib's build-aux/move-if-
change is copied into the package's build-aux directory, rather than assuming
move-if-change is on PATH? Or maybe we could write this as move_if_change ?=
$(gnulib_dir)/build-aux/move-if-change?
M4 had some rules for creating deltas, such as m4-1.4.12-1.4.13.diff.gz; are
these worth keeping around, or are we at the point now where it is easier to
tell users to install the complete tarball rather than trying to apply a delta
to a previous tarball?
--
Eric Blake
- maint.mk questions,
Eric Blake <=