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
