bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

maint.mk syntax check problems


From: Martin von Gagern
Subject: maint.mk syntax check problems
Date: Mon, 05 Sep 2011 14:16:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110831 Thunderbird/6.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]