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
