bug-gnulib
[Top][All Lists]
Advanced

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

Re: rules, rules, and more (code policy) rules


From: Simon Josefsson
Subject: Re: rules, rules, and more (code policy) rules
Date: Fri, 10 Feb 2006 16:44:59 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Jim Meyering <address@hidden> writes:

> Simon Josefsson <address@hidden> wrote:
>> Jim Meyering <address@hidden> writes:
>>> I tend to forget, too, so have automated quite a few policy checks,
>>> over the years.  You might try adding some checks like those in coreutils'
>>> Makefile.maint.  Here are the syntax-check (sc) target names:
>>
>> These are very useful tests.  I'd like to adopt them in my projects.
>> Is there some way they could be moved to gnulib?  And perhaps
>> modularize them somewhat.  For example, even if I currently use CVS
>> for my projects, separating out the tests that assume CVS seems like a
>> good idea.
>
> Hi Simon,
>
> Nearly all of those rules -- certainly the new ones -- require a version
> control system.  For coreutils, I'm still using cvs, but it should be easy
> to adapt to others.  The main functionality required is to be able to list
> all of the version-controlled files so that we don't get false positives
> on non-version-controlled (e.g., generated) files that happen to be in a
> working directory.  Currently that's done by the build-aux/cvsu script.
> Tweaking things to work also for svn, monotone, git, arch, mercurial, svk,
> etc. shouldn't be hard.

Ah, right.  That was mostly an idea I had, I didn't look too carefully
at the tests.

I want to make sure that some useful tests doesn't depend on something
else that may not be generally applicable.  That was the reason I
stoped using Makefile.maint some time ago (I did use it in libidn).

> You're welcome to generalize/modularize/whatever things and put the
> result in gnulib.  Be aware that some of the rules enforce controversial
> (to Bruno, at least :-) policies, so it may not be reasonable to apply
> them to all of gnulib.  But that's why every rule has an exclusion mechanism.

I propose to add some foo.mk that contain all the rules.  Including
that file in any makefile should be harmless.  Each maintainer have to
invoke the targets in that file manually, or through some custom
script.  What do you think?

On second thought, there could be one file per test.  That may make it
more modular.  Yes, I think this is better.

How to connect this to gnulib-tool is still unclear to me.

> Also, if you want to skip some of these syntax-check tests altogether,
> just define a Make variable, local-checks-to-skip, and set it to the
> corresponding list of rule names.

By default, I'm not sure all of the syntax tests should be run at all.
Let's start out by small steps.  Of course, writing a pseduo-target
'syntax-checks' that invoke all other syntax checks is certainly
possible.

Later on, we could enforce some syntax checks on code imported into
gnulib.

>> Scripts like gnupload, announce-gen, etc may also be useful to move to
>> gnulib?
>
> Sure!  It'd help us all stay in sync.  gnupload started in automake,
> and is now used by quite a few other projects.  Plus, I know of
> a few projects that are using older versions of announce-gen.
>
> Have you just volunteered? :-)

I guess so.  gendocs.sh and gendoc-template from texinfo is also
applicable.  I use gdoc in my projects, but it is not owned by FSF (it
is GPL though).

I'll submit things separately.

Thanks.




reply via email to

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