maint.mk sc_copyright_check won't handle multiple lines
Hi! The sc_copyright_check in maint.mk won't handle a copyright notice spanning multiple lines. For wdiff I'll likely disable that check for this reason, since keeping 9 years in a single copyright line for the texi file doesn't agree with my own ideas of readable sources. It would be great if you could come up with some solution which does that check but takes copyright lines spanning multiple lines into account. Probably a perl script, I guess. I dimly remember some discussion about perl for syntax checks: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/28103/focus=28257 Did anything ever come out of this? Doesn't look that way to me, but I don't closely follow the list. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature
Syntax checks in perl (was: Re: maint.mk syntax check problems)
On 15.09.2011 11:37, Jim Meyering wrote:
I'm sure that a perl-based
implementation would be far more efficient, and probably faster
even if the perl implementation doesn't run its tests in parallel.
Perl is well suited to this task.
I'm sure some will object to Perl's syntax, but not I.
Not that I object to Perl, but as we are discussing different languages,
I'd like to offr Python as an alternative to consider. Main benefits:
- threading and therefore parallel tests
- clean exception handling, allowing checks to fail in deeply nested
code and still recover to proceed with the next check
- somewhat mere legible syntax, I believe
I'm not sure if these benefits warrant adding another scripting language
both to the set of tools maintainers are expected to have around and to
the set of languages to maintain within gnulib.
With a good Perl-based harness, I'll certainly be glad to phase
out (of projects I maintain) the make-based tests.
Me, too.
On 15.09.2011 11:14, Stefano Lattarini wrote:
About an yaer ago I had proposed a similar move for automake's own
maintainer checks; see this RFC patch:
http://lists.gnu.org/archive/html/automake-patches/2010-07/msg00081.html
A good start! My main concerns are that for one, the framework might not
be flexible enough. The approach is well suited for checks processing
one line at a time, but checks that operate on the file text as a whole,
or that even pass the file to some other tool (e.g. indent), are rather
difficult to express. It would be nice if such test types could at least
be added later on with reasonable overhead.
To add some flexibility for future extensions, I believe that it would
be good to use some OOP approach, i.e. have test classes. Instances of
each class could be configured using keywords, which I very much like
about that approach. Most current checks, both from that batch and
maint.mk, would probably be instances of some regexp-checking class. But
others could be added later on.
Perhaps the regular expressions could operate on the whole file by
default, although that makes obtaining the offending pieces of code a
bit harder. But line breaks don't really matter in C, so looking even
accross them would be the right thing to do for many checks.
Some checks might operate on a different set of files than others, e.g.
generated files instead of version-controlled ones. Current maint.mk
does that for sc_po_check as well as those checks passing in_files to
_sc_search_regexp: sc_copyright_check, sc_Wundef_boolean and
sc_vulnerable_makefile_CVE-2009-4029. So file name alone isn't enough.
In case some more complicated checks want to exit a single check from
somewhere inside nested code, I would like to wrap all check execution
in eval { ... } so that a die within that code can be recovered
from. Although I must confess that this would make more sense with a
one-check-at-a-time look as the outermost one, whereas the proposed perl
script does one-file-at-a-time, saving io but causing repeated check calls.
The proposed script apparently has no means of configuration so far. I
guess it would be great if the configuration file were a perl script
itself, so it could not only modify the configuration affecting existing
checks, but even add completely new checks specific to a given project.
One more thing: at least for me, the above link does obfuscate large
parts of perl code which it incorrectly considers to contain e-mail
addresses, replacing those portions with address@hidden. So some other
archived version of that mail must be used, e.g.
http://article.gmane.org/gmane.comp.sysutils.automake.patches/4302
Glad things were set in motion,
Martin
signature.asc
Description: OpenPGP digital signature
Re: Syntax checks in perl
Hi Stefano. On 15.09.2011 21:08, Stefano Lattarini wrote: Perl versions from 5.8 onwards should have a threading interface too, if I'm not mistaken. I don't know how powerful or easy-to-use it is, though. Afaik ithreads support is an optional feature, not sure how distros out there handle it. I've got it installed here on my Gentoo, but had to explicitely enable it. perldoc threads has docs on this, looks reasonably simple. - clean exception handling, allowing checks to fail in deeply nested code and still recover to proceed with the next check That is possible in perl too (even if it requires various hoops, while being very natural in python). OK, emphasis on CLEAN. Perl hoops look less than clean, and I guess we don't want to depend on third party modules like Exception::Class, TryCatch or Try::Tiny. Plain die/eval should be sufficient here, though. Good! But consider that it might take some time before I post something usable though (a month or two isn't an unreasonable guess). No worry, as long as I know things are progressing, I'm very patient on this. To add some flexibility for future extensions, I believe that it would be good to use some OOP approach, i.e. have test classes. Good idea (but let's call those check classes, please :-) For give a native German speaker, I tend to mix those two up unless I make a conscious effort. Two caveats though, if we go down this road: - We should be careful not to over-engineer, especially in the earlier phases. Not over-engineer, but still keep future requirements in mind and make sure we're not too narrow-minded in our engineering either. - We should have a testsuite for the new code; since this new code would mostly be intended for in-house use at first, we don't need a really industrial-strenght coverage, but some automated testing will be definitely required. Sounds reasonable, as long as the suite has no impact on projects importing gnulib. Perhaps the regular expressions could operate on the whole file by default, Or we should provide a config varible to decide the default matching unit -- file or line. Optional config var, sure, why not. But there should be a sane default, so that at most half the (currently envisioned) tests need an explicit configuration. At least, for check intended for C files. Things might be different for checks aimed at makefile fragments or shell scripts. Not that different, I guess. Compiling a regexp with the 'm' flag and without the 's' flag should ensure that ., ^ and $ behave just as they would for single-line matches. So as long as checks use [^ \t] or similar instead of \s, they should probably be on the safe side even if executed on the file as a whole. The code could operate adaptively: if the list of files is an actual list reference, just use it; if it's a scalar, pass it to the 'glob()' builtin to obtain a list of files; if it is a code reference, call it (with args, and if yes, which ones? that's to be decided) to fetch the list of files; and so on (we could devise semantics also for hash references, regular expression objects, or custom objects, maybe). Sounds reasonable. Again, we should have a sane default, which should represent the list of all versioned files. And we should have separate filtering rules, to select parts of that list. This gives us three layers: 1. Source list: glob, vc-list, explicitely named, or similar. 2. Check-driven filters, e.g. by file extension or by directory 3. Project-configured filters, blackliting some of the remaining files The tricky part will be to decide how to operate properly under VPATH builds ... As syntax checks do check for source-level issues, I guess we could live with requiring an in-tree build, at least for now. Greetings, Martin signature.asc Description: OpenPGP digital signature
Re: maint.mk syntax check problems
Hi Bruno, thanks for your reply! On 05.09.2011 21:45, Bruno Haible wrote: I don't think it makes sense to run such stylistic checks on files that are not under your control. po/Makefile.in.in is owned by the gettext maintainer, and the *.po files are in the hands of the translators. In other words: I would disable these checks for the po/ directory. Makes sense. Will only have to figure out what exactly these checks entails, as I believe that there are syntax checks which should apply to those files as well, for the sake of portability. I wonder whether it makes sense to split syntax checks into two groups, one for minor issues which you should fix if things are under your control, and one for major things which you should report upstream if things are out of your control? I'm not sure the border between these two will be clear, so I'm not convinced myself, but I know I don't fancy adjusting the exclusions whenever gnulib adds a (minor) syntax check which my code fails for some reason. Note that the sc_prohibit_doubled_word check could fail for files under the maintainer's control as well, e.g. for non-ASCII source code comments, names in particular. Chances are even smaller, but I still consider the check slightly broken. Greetings, Martin signature.asc Description: OpenPGP digital signature
Re: maint.mk syntax check problems
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
Re: maint.mk syntax check problems
Thanks, Jim, for the swift reply this time! On 14.09.2011 14:49, Jim Meyering wrote: 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. Most projects do not version-control maint.mk. IMHO, the cost of obfuscating the strings in maint.mk (in comments) that trigger warnings would be too high, rendering the comments significantly harder to read. At least for the at-at check, restricting that to non-comment lines would both make maint.mk pass as well and allow Makefile.ams out in the wild refer to the corresponding substitution patterns. But I see your point. If you must version-control a copy of maint.mk, you may still exempt it from its own checks by setting a couple of variables in cfg.mk. Did so for now, but will probably adjust the wording to indicate that these exemtions are expected to stay. 4. Obscure sc_tight_scope: Thanks. That was a bug. Fixed by the patch below. Great! 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. gl_other_headers_ is defined like this: gl_other_headers_ ?= \ intprops.h\ openat.h \ stat-macros.h The ?= assignment means that you can override it via cfg.mk. Does that work for you? Means I'd have to keep that list updated when gnulib changes its header organization, or when I change the list of modules I import, or whatever. As I'm patching maint.mk in any case, I feel better using the modification mentioned above. I guess others might feel the same. After all, those headers come from gnulib, so the list should be maintained with gnulib as well. And checking files that don't exist is never going to make any sense. 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. Again, the default generated_files definition in maint.mk may be overridden by a project-specific definition, say in cfg.mk. Again, did that to work around the issue, but having to tweak that cfg.mk after every gnulib update isn't exactly my idea of easy-to-use software. So I wondered whether it would be better to move the load of these adjustments off the projects using gnulib and into gnulib itself. If I'm about the only maintainer having gnulib in his repo, I'll accept that at least maint.mk doesn't officially support this, will work around issues myself and stop bothering you. But if there are others like me, even if they are few, then I'd prefer things to work out of the box. It might not be worth the effort/disruption. One advantage of using Makefile rules is that it's easy to override the defaults, as you see in the examples above. Not so hard with shell scripts either. Use source cfg.sh instead of -include ./cfg.mk and everything should be about the same. As I don't see cfg.mk containing many settings that apply to both syntax checks and other aspects of maint.mk. Those few that might be present could be explicitely passed to the shell script via environment or command line. Greetings, Martin signature.asc Description: OpenPGP digital signature
Re: maint.mk syntax check problems
Re-sending for the mailing list, forgot that a moment ago. On 14.09.2011 16:49, Simon Josefsson wrote: I'm not a fan of separate shell scripts, each new file to deal with seems to incur a small maintainance cost over time -- consider when they are renamed or moved. I think gnulib already install a large number of of files into projects using gnulib, so we should be conservative about increasing that number needlessly. You could integrate vc-list-files into that file as a function, thus keeping the number of files the same. Would have the added benefit that the result of the listing could be cached in a bash array, making my own caching from https://github.com/gagern/gnulib/commit/40533f3fa4b9 obsolete. I guess you could also turn this into a perl script instead of a bash script, but while that would allow integration of the existing perl scripts useless-if-before-free, announce-gen and update-copyright, and would make some regexp checks easier, it would mean rewriting the checks considerably. Some checks would probably be less readable than their shell equivalent. And perhaps some projects might be using one of the existing perl scripts independently from maint.mk. In general I'm in favor of as simple code as possible, but I think here the cost with many new shell scripts outweigh the benefit of improved code. Just to make certain there is no misunderstanding: I'm thinking about a single file containing all these scripts as functions, not multiple files with one test each, as your answer might possibly suggest. Martin signature.asc Description: OpenPGP digital signature
maint.mk syntax check problems
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
gettext 0.17 legacy
Hi there! Commit 190bf61ecbb3727a3dd742498938be9e251f9315 on 2010-05-09 updated gettext from 0.17 to 0.18, but left the file build-aux/po/Makefile.in.in in its old form from gettext-0.17. This will cause problems for packages that use separate po files for gnulib. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature
maint.mk sc_prohibit_always_true_header_tests: bad cd
Hi there! Running make sc_prohibit_always_true_header_tests causes a cd invocation to fail, without make aborting: prohibit_always_true_header_tests /bin/sh: line 0: cd: ./gnulib/lib: No such file or directory It would be nice to actually check that $(gnulib_dir) exists, and either skip the check (like sc_prohibit_always-defined_macros does) or error out if that dir doesn't exist. I wonder whether gnulib is a sane initial value for that dir. I at least have gnulib at the root of my source tree, and I somehow got the impression that many projects might, so . would be better. I also wonder whether the /lib subdir should be configurable as well. But there are a lot of hardwired dirs in maint.mk, and if one were to fix this, one should do so consistently, I think. Greetings, Martin signature.asc Description: OpenPGP digital signature
maint.mk sc_prohibit_always-defined_macros complains about build-aux/warn-on-use.h
Hi there! I've got gnulib in my repository, so devs don't need a git checkout. When I last ran the syntax checks from maint.mk, I got a false positive from prohibit_always-defined_macros complaining about the definition of environ in build-aux/warn-on-use.h. The error is due to the following line in warn-on-use.h # define environ (*rpl_environ ()) which conflicts with definitions from unistd.in.h. Maybe you should alter that file so it doesn't match the rule. Or you should explicitely exclude it from the list of files to check. In my package, wdiff, I've excluded the whole build-aux directory from that check, but I can easily do so without creating extra files due to my personal modifications to gnulib. http://github.com/gagern/gnulib/commit/57646d674f68676ca3b9 I guess I should try to get my gnulib copyright assignment forms completed so you can include this upstream as well... Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature
Re: [wdiff-bugs] wdiff-0.6.1 build problems
Hi there!
Nelson H. F. Beebe reports problems building Gnulib sources shipped with
wdiff 0.6.1. Those sources should be up to date, so current git should
exhibit these problems as well.
On 02.04.2010 20:58, Nelson H. F. Beebe wrote:
On Solaris 7 SPARC, compilation with cc fails like this:
cc -DHAVE_CONFIG_H -I. -I.. -DDEFAULT_TEXT_DOMAIN=\wdiff-gnulib\
-I../intl -I/usr/local/include -I/usr/local/include -c localcharset.c
./getopt.h, line 31: empty file name
cc: acomp failed for localcharset.c
I did a fresh build using gcc-2.95.3 (the last gcc version that builds
on that O/S), and that solved the problem.
See his full report in the wdiff-bugs list archive:
http://lists.gnu.org/archive/html/wdiff-bugs/2010-04/msg2.html
Can you imagine what's causing this?
Do you have an idea how to avoid this?
Do you want to address this even if a gcc update solves the issue?
I've asked Nelson for additional information, config.{log,status} in
particular, so maybe we can provide more details soon.
Greetings,
Martin von Gagern
signature.asc
Description: OpenPGP digital signature
Re: maintainer-makefile troubles and suggestions
On 31.01.2010 19:11, Bruno Haible wrote: There is the possibility to use approach 3, by - using the gnulib-tool options --po-base and --po-domain, - defining the DEFAULT_TEXT_DOMAIN macro in lib/Makefile.am. The PO files for gnulib will be automatically downloaded from the Translation Project's website http://translationproject.org/domain/gnulib.html. This approach should certainly be better documented and more used. Thank you, Bruno, that is indeed a good solution. Saved my translators 30 strings. With that configuration in place I only had to remove the gnulib dirs from the sc_po_check check in maint.mk. I guess I could write a patch to detect use of po-base, and auto-adjust the check accordingly. However, as my gnulib assignment form hasn't even arrived here yet, I'm reluctant to write more patches that cannot be legally included yet. So if someone who's already done the paperwork wants to have a look, I'd be glad. Martin signature.asc Description: OpenPGP digital signature
Improvements for maint.mk
Hello! As I just wrote a lengthy email of issues I noticed with maint.mk, here are a few patches dealing with some of them. I hope you can apply them to gnulib. As for the copyright: I've already assigned copyright for wdiff to the fsf. Do I have to repeat all the paperwork, or can I simply commit my modifications to the wdiff tree in order to make them officially owned by the FSF? Greetings, Martin von Gagern
[PATCH 1/4] vc-list-files: List bzr files recursively.
bzr ls isn't recursive by default, so we have to add the --recursive flag. The short form would have been -R, but as the script uses --versioned instead of -V, using the long option seems more consistent. --- build-aux/vc-list-files |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/build-aux/vc-list-files b/build-aux/vc-list-files index c07576d..41ecebd 100755 --- a/build-aux/vc-list-files +++ b/build-aux/vc-list-files @@ -2,7 +2,7 @@ # List version-controlled file names. # Print a version string. -scriptversion=2009-07-21.16; # UTC +scriptversion=2010-01-21.13; # UTC # Copyright (C) 2006-2010 Free Software Foundation, Inc. @@ -85,7 +85,7 @@ elif test -d .hg; then eval exec hg locate '$dir/*' $postprocess elif test -d .bzr; then test $postprocess = '' postprocess=| sed 's|^\./||' - eval exec bzr ls --versioned '$dir' $postprocess + eval exec bzr ls --versioned --recursive '$dir' $postprocess elif test -d CVS; then test $postprocess = '' postprocess=| sed 's|^\./||' if test -x build-aux/cvsu; then -- 1.6.6
[PATCH 2/4] maint.mk: cache VC_LIST output.
Several syntax checks work on the list of all versioned files. Regenerating
this list for every such check can be quite time-consuming. To avoid this,
a wrapper target could generate this list once, perform all checks, and
clean up the list afterwards.
As an added benefit, this allows us to pass -k (--keep-going) to the
sub-make, so that it will perform all syntax checks instead of aborting at
the first one to fail.
---
top/maint.mk |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/top/maint.mk b/top/maint.mk
index 366d12a..2a90932 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -112,7 +112,11 @@ $(patsubst %, %.m, $(syntax-check-rules)):
local-check := $(filter-out $(local-checks-to-skip), $(local-checks-available))
-syntax-check: $(local-check)
+syntax-check:
+ @$(VC_LIST) .vc.list
+ @$(MAKE) -k $(local-check) VC_LIST='cat .vc.list'
+ @$(RM) .vc.list
+
# @grep -nE '# *include (limits|std(def|arg|bool))\.h' \
# $$(find -type f -name '*.[chly]') \
#{ echo '$(ME): found conditional include' 12; \
@@ -776,7 +780,7 @@ no-submodule-changes:
.PHONY: alpha beta stable
ALL_RECURSIVE_TARGETS += alpha beta stable
-alpha beta stable: $(local-check) writable-files no-submodule-changes
+alpha beta stable: syntax-check writable-files no-submodule-changes
test $@ = stable\
{ echo $(VERSION) | grep -E '^[0-9]+(\.[0-9]+)+$$' \
|| { echo invalid version string: $(VERSION) 12; exit 1;};}\
--
1.6.6
[PATCH 3/4] maint.mk: Update translations using rsync instead of wget.
Checksums (-c) are used instead of timestamps (-t) to check whether a file is already up to date. This allows integration with version control systems that usually don't preserve timestamps. The listing of files was changed from verbose (-v) to itemize (-i) so it becomes easier to distinguish updated files from new ones. See also http://translationproject.org/html/maintainers.html --- top/maint.mk | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/top/maint.mk b/top/maint.mk index 2a90932..438d3ab 100644 --- a/top/maint.mk +++ b/top/maint.mk @@ -848,12 +848,16 @@ coverage: init-coverage build-coverage gen-coverage # Update gettext files. PACKAGE ?= $(shell basename $(PWD)) PO_DOMAIN ?= $(PACKAGE) -POURL = http://translationproject.org/latest/$(PO_DOMAIN)/ PODIR ?= po +RSYNC_OPTIONS = -iz +RSYNC_PROTECT ?= e...@boldquot.po e...@quot.po +.PHONY: refresh-po refresh-po: - rm -f $(PODIR)/*.po \ - echo $(ME): getting translations into po (please ignore the robots.txt ERROR 404)... \ - wget --no-verbose --directory-prefix $(PODIR) --no-directories --recursive --level 1 --accept .po --accept .po.1 $(POURL) \ + @echo $(ME): getting translations into $(PODIR)... + rsync $(RSYNC_OPTIONS) -Lrc --delete \ + $(patsubst %,-f 'protect %',$(RSYNC_PROTECT)) \ + -f 'include *.po' -f 'exclude *' \ + translationproject.org::tp/latest/$(PO_DOMAIN)/ $(PODIR) echo 'e...@boldquot' $(PODIR)/LINGUAS \ echo 'e...@quot' $(PODIR)/LINGUAS \ ls $(PODIR)/*.po | sed 's/\.po//' | sed 's,$(PODIR)/,,' | sort $(PODIR)/LINGUAS -- 1.6.6
[PATCH 4/4] maint.mk: Imporved LINGUAS generation.
This change avoids duplicates for e...@boldquot and e...@quot. It also ensures
that the list is completely sorted and that any comment lines preceding the
list of linguas will be preserved. Non-lingua lines following the list of
linguas will be moved in front of the linguas, so it is suggested to avoid
any such lines. A header should be enough.
---
top/maint.mk |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/top/maint.mk b/top/maint.mk
index 438d3ab..644e4b1 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -858,9 +858,10 @@ refresh-po:
$(patsubst %,-f 'protect %',$(RSYNC_PROTECT)) \
-f 'include *.po' -f 'exclude *' \
translationproject.org::tp/latest/$(PO_DOMAIN)/ $(PODIR)
- echo 'e...@boldquot' $(PODIR)/LINGUAS \
- echo 'e...@quot' $(PODIR)/LINGUAS \
- ls $(PODIR)/*.po | sed 's/\.po//' | sed 's,$(PODIR)/,,' | sort
$(PODIR)/LINGUAS
+ @touch $(PODIR)/LINGUAS
+ sed -ie '/^[a-z]/d' $(PODIR)/LINGUAS
+ { echo 'e...@boldquot'; echo 'e...@quot'; ls $(PODIR)/*.po; } \
+ | sed -e 's/\.po//' -e 's,$(PODIR)/,,' | sort -u $(PODIR)/LINGUAS
INDENT_SOURCES ?= $(C_SOURCES)
.PHONY: indent
--
1.6.6
Re: [PATCH 4/4] maint.mk: Imporved LINGUAS generation.
On 21.01.2010 15:39, Martin von Gagern wrote: + sed -ie '/^[a-z]/d' $(PODIR)/LINGUAS ^^^ That should have been -i -e instead, as the -i option to sed takes an optional argument. Sorry. I've incorporated my changes into wdiff by now: http://bzr.savannah.gnu.org/lh/wdiff/trunk/revision/58 Maybe that makes it easier to include them into gnulib as well. Martin signature.asc Description: OpenPGP digital signature
Re: maintainer-makefile troubles and suggestions
Hi Eric! On 21.01.2010 17:10, Eric Blake wrote: Thanks for all the feedback! I've got two more. sc_prohibit_atoi_atof: -- The comment claims that [fs]?scanf doesn't provide error feedback. The return value section of my scanf(3) man page says differently: the number of successful conversions is returned, which is quite a suitable error indication in many cases, I believe. sc_prohibit_strcmp: --- Judging from the lib/streq.h file, STREQ seems to be only suitable for comparison with fixed strings of lengths up to 9. Furthermore, its invocation with both the string and the padded list of characters make it quite bulky and hard to read. So I'd only suggest it in performance-critical areas, never as a general rule. Maybe you should have some kind of default test suite, so that people can add such tests in corner cases but the default set is suitable for most people and doesn't include such checks? I haven't looked closely at your fixes or at any of the points where you haven't yet provided patches, except for this one: Funy, you write one and comment on three... :-) That's already been patched in autoconf: That's good to know. Thanks! Yes, it would be nice for automake to learn more about autotest. I'm sure Ralf would welcome patches. But it hasn't been enough of an itch for me (yet) to try writing such a patch. Can't get involved with that as well. gnulib is already more time right now than I really can afford. You can exclude files specific to your project, using .x-* files. I've been doing that, until I got fed up with those additional files lying around and decided to put all that stuff in cfg.mk: http://bzr.savannah.gnu.org/lh/wdiff/trunk/revision/66 It's a single line change, and likely easier applied manually than automatically, at least after Jim applied the patches he just wrote about. If you want me to, I can still send you a git patch, though. Also, many projects tend to NOT version control generated files, like po/Makefile.in.in, since they can be rebuilt during bootstrap. Yes, and I would do so if I one of two conditions were met. If either I could rely on distros to provide suitable gnulib packages, so that autogen.sh could have a line for gnulib-tool --update and still be expected to work on machines with basic package building software. Or if I could rely on gnulib playing nice with gettext, so that I could have gnulib in source and could still expect autopoint to perform its work. As it is, I don't intend to drop gnulib code from the version controlled tree, as there are (intentionally!) no releases, and as adding git or cvs checkout code to autogen.sh feels evil. And if I have gnulib in tree but not gettext, then autopoint (from gettext 0.17) will complain that some files have been modified, and will refuse to install any still-missing files. Plus I'd force all developers building from the repository to have latest gettext installed, because gnulib only supports latest gettext officially. Pretty ugly situation, I think. 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 If it were up to me, I'd like to see BOTH rsync and wget supported. Why? Because half of my day, I'm stuck behind a firewall where wget can get through, but not rsync; but rsync does perform faster if there's not a firewall in the way. The same goes for grabbing translation files in the gnulib bootstrap script. But again, not something where I've had time to even think about patching it. In that case I'd suggest two targets, so you can call the suitable one manually. You can always add fancy auto-selection one day when you have a brilliant idea for it. Greetings, Martin
