bug-gnulib
[Top][All Lists]
Advanced

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

Re: maint.mk syntax check problems


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

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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