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
