Re: maint.mk syntax check problems

[Martin von Gagern]

Hi!

I recently wrote a mail with various remarks about how maint.mk syntax
checks give false positives, and some suggestions to avoid these. Bruno
Haible was kind enough to voice an opinion on items 2 and 3 of that
list, but I have seen no reply to any of the other problems.

And I'm still interested in some feedback what you think about turning
those syntax checks into a shell script file instead of embedding so
much ugly backslash-continued shell code into the makefile.

Hoping for some more reaction,
 Martin von Gagern

On 05.09.2011 14:16, Martin von Gagern wrote:
> Hi!
> 
> I'm currently updating GNU wdiff to use latest gnulib, 2c53fc42. In the
> process, I've encountered a number of problems with maint.mk syntax checks.
> 
> 
> 1. main.mk fails its own checks:
> 
> The checks sc_makefile_at_at_check and sc_prohibit_undesirable_word_seq
> both fail for me, as the maint.mk file itself violates these checks.
> 
> I know, this will probably only affect projects which have gnulib
> included in their own repository, but according to the manual
> <http://www.gnu.org/software/gnulib/manual/gnulib.html#VCS-Issues> that
> approach is officially supported, so the checks should deal with it.
> 
> 
> 2. sc_prohibit_undesirable_word_seq and gettext:
> 
> Makefile.in.in as generated by gettextize will contain the undesirable
> phrase "can not", due to
> <http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=b9f19ed7f6cedcb1435e8d9c906646c37f01d2f5>.
> Will someone who is a native English speaker take this up to the gettext
> guys, and kindlky ask them to address this? Or are people like Bruno
> Haible sufficiently involved in both projects that someone will likely
> read this mail and fix that phrase, without further mails required?
> 
> 
> 3. sc_prohibit_doubled_word and non-ASCII text:
> 
> In my po/pt_BR.po file
> <http://bzr.savannah.gnu.org/lh/wdiff/trunk/annotate/77.1.7/po/pt_BR.po#L965>
> I have the text "no conteúdo do arquivo", encoded in ISO-8859-1. Perl
> wasn't told to use any specific unicode-aware mode, and apparently
> didn't consider the 'ú' a word character. So the change from 'ú' to 'd'
> constituted a word boundary, causing the line to be forbidden.
> 
> I tried to address this using ignore_doubled_word_match_RE_, but
> unfortunately the perl script only prints the matching part of the line,
> not the whole line. So I cannot mask the error using a regexp like
> 'conte..?do.do', as the line only contains the "do do" all by itself. It
> would generally be better to print the whole offending line.
> 
> And in the long run, it would be nice if you could persuade Perl to
> consider any non-ascii characters as word characters for this test. In
> dubio pro reo.
> 
> 
> 4. Obscure sc_tight_scope:
> 
> The syntax check printed a message indicating that it skipped the
> tight_scope check. I still don't know what this check is about, but
> reading the code I found that it sometimes sets a variable called
> "fail", but that variable doesn't appear to affect the result in any
> way. Other syntax checks have "test $$fail = 1" as a condition
> somewhere, but tight_scope does not. So no matter what the test is
> supposed do, I'd gues it currently doesn't do it.
> 
> 
> 5. sc_prohibit_always-defined_macros reports missing files:
> 
> The sc_prohibit_always-defined_macros check will cause error messages
> about missing files to be emitted if elements from the gl_other_headers_
> list are not present (i.e. not imported). This can be confusing. I've
> added a "test -e $$f" check to the def_sym_regex code:
> https://github.com/gagern/gnulib/commit/74524a2c993a809bbc20dcc3
> Feel free to merge this.
> 
> 
> 6. sc_po_check and generated files:
> 
> If gnulib has its own po-base, then $(generated_files) should not be
> included in the list of files to check, as the main project POTFILES.in
> isn't responsible for these. Checking whether the po-base specific file
> $(srcdir)/lib/po/POTFILES.in exists might be a good way to discern these
> scenarios.
> 
> 
> On the whole, I wonder whether it would be better to factor all of these
> syntax checks from the makefile into a separate shell script file. After
> all, most of them are largely composed of shell syntax snippets already.
> And a shell script file would get rid of a HUGE number of line
> continuation backslashes. It would probably also make things like output
> coloring easier, I believe, as you could nest functions more easily.
> What do you think?
> 
> By the way, big thanks to Jim Meyering for commit 0baae9ca, finally
> making those source code exclusions use variables instead of files!
> Finally obsoletes my own modification to that effect:
> http://bzr.savannah.gnu.org/lh/wdiff/trunk/revision/66 as discussed in
> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/20443/focus=20454
> 
> 
> Greetings,
>  Martin von Gagern

signature.asc
Description: OpenPGP digital signature