Re: maint.mk questions

[Jim Meyering]

Eric Blake wrote:
> 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)'

Good idea.

> 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

Did you mean to make news-date-check depend on version-check?

>         today=`date +%Y-%m-%d`;                                         \
> -   if head $(srcdir)/NEWS | grep '^\*.* $(VERSION_REGEXP) ('$$today')'     \
> + if head NEWS | grep '^\*.* $(VERSION_REGEXP) ('$$today')'   \

Good change.
Thanks.

> Likewise for vc-diff-check:
>
>  vc-diff-check:
> -   (CDPATH=; cd $(srcdir) && $(VC) diff) > vc-diffs || :
> + $(VC) diff > vc-diffs || :

Ditto.

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

Right.  They should be safe, except for
install-transform-check, which will fail if, like parted,
a package installs into $(prefix)/sbin by default.
There, I had to change a hard-coded /bin/ or two to /sbin/.

I'll move those into coreutils/cfg.mk.

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

Good idea.
If you do this, please add something in maint.mk
to ensure that the variable is defined.

> +# 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?

Whichever you prefer is fine with me.
Hmm... does anyone use that?
Maybe we can just remove it.
I see there is no longer any use of move.if.change in coreutils.

If you feel like preparing a patch for the above, that'd be great.

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

I'm convinced that deltas are no longer worth the effort.
No one has ever told me that they'd like to keep them,
or later, to have them restored when I stopped distributing them
for coreutils.