maintainer-makefile troubles and suggestions

[Martin von Gagern]

Hi there!

I've got a few troubles with the maintainer-makefile module. Basically
I'm just trying to get "make beta" to work (on my GNU wdiff development
tree, where I just imported it).

Here's a list of things that either caused me trouble or made me think.
Some aspects of it involve parts of gnulib besides maint.mk.


build_aux:
----------

maint.mk uses a variable build_aux, while GNUmakefile has _build-aux for
apparently the same directory. They should be unified.

If the correct directory could be automagically included by gnulib-tool
(which knows what aux dir it's using, after all), that would be even better.


VC_LIST:
--------

That command is eating most of the time for me with bzr (after I fixed a
bug in vc-list-files, which I'll report separately). The main reason is
that it is unneccessarily called for each and every syntax check. I
could get a factor 100 speedup with the following:

-syntax-check: $(local-check)
+syntax-check:
+       @$(VC_LIST) > .vc.list
+       @$(MAKE) -k $(local-check) VC_LIST='cat .vc.list'
+       @$(RM) .vc.list

As a benefit, one failing syntax checks won't abort the checking, which
I consider a good thing.

Of course, the $(local-check) reference for "alpha beta stable" should
be changed to syntax-check as well, so it will profit from the same
performance boost.

I'll try to submit a git patch for all of this shortly.


sc_immutable_NEWS:
------------------

A nicer error message if old_NEWS_hash is unset would be nice.

Why is old_NEWS_hash stored in cfg.mk, but PREV_VERSION in
.prev_version_file? I'd welcome a unified approach to these.

The NEWS_hash macro assumes that release entries in the NEWS file start
with an asterisk in the first column. As the GNU coding standards make
no such restriction, it would be nice if users could adjust that regexp
by setting some macro in cfg.mk.


sc_makefile_at_at_check:
------------------------

That one contradicts the suggested practice from the current autoconf
documentation with regard to autotest:
http://www.gnu.org/software/autoconf/manual/html_node/Making-testsuite-Scripts.html

Personally I'd prefer it if automake could create all that boilerplace
code automatically, or maybe you could include a makefile to do this, or
use @variable@ substitution to provide it, or whatever. Until that
happens, some clarification of this discrepancy would be nice.


sc_makefile_TAB_only_indentation:
sc_makefile_path_separator_check:
---------------------------------

These complains about the po/Makefile.in.in installed by gettext 0.17.
Perhaps you want to exclude that file, or file a bug against gettext? Or
did someone already do so? It would be nice to know if these checks
actually ensure portability, or simply improve legibility.


syntax-check:
-------------

Some parts of gnulib itself fail some syntax checks. It would be nice if
this could be avoided.

The sc_FOO.m targets used to print syntax checks aren't .PHONY.


sc_po_check:
------------

This one complains about files like lib/getopt.c not being listed as
requiring translations. OK, it has a point there. Still, of the three
possible solutions which come to my mind, none feels exactly right:

1. Add files, and require every translator of every module using gnulib
to re-include the same old translations, or even worse, think of similar
but different translations every time. It would be nice if the list of
files to be added in this way could be maintained by gnulib.

2. Drop all localizing constructs from getopt.c and accept that messages
won't be localized unless the system has a properly localized
gnu-compatible getopt library installed. Same for other, similar
replacement files, e.g. regcomp.c.

3. Have gnulib use a different domain, have the proper message files
imported along with the rest of gnulib into the project source tree at
pre-configure time, and have those files compiled and installed at make
time if any of the replacement files requiring them is actually used.

I haven't been able to find a discussion of this point on the bug-gnulib
mailing list yet. There is one about dependency, including a list of
affected gnulib modules, dating from 2005:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/3608/focus=3611


refresh-po:
-----------

Why do you use wget here, instead of rsync as suggested on the
Translation Project info for package maintainers:
http://translationproject.org/html/maintainers.html

Of course, when building from a repository, timestamps are a poor
indication of up-to-dateness of files. So I'd change the -t to a -c to
have rsync checksum files. As a result, if nothing has changed, then the
refresh should be a lot faster than it would be using wget.

Will send a git patch for this later on as well.


emit_upload_commands:
---------------------

Why emit the gnupload command instead of actually executing it? Or how
about introducing a switch for it, so users can change behaviour on the
command line or in cfg.mk?


Despite these issues, maintainer-makefile seems like a good idea, and
has a lot of potential. Thanks!
 Martin von Gagern

signature.asc
Description: OpenPGP digital signature