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: Jim Meyering
Subject: Re: rules, rules, and more (code policy) rules
Date: Sun, 12 Feb 2006 15:00:16 +0100

Simon Josefsson <address@hidden> wrote:
> I think CVS_LIST has some disadvantages:
>
> * Unrelated to the core problem.  The core problem is "how to list all
>   C code or header files".  Even if you use CVS_LIST, you'll have to
>   filter it further, excluding generated files the maintainer has no
>   control over, and include generated files the maintainer has control
>   over.
>
> * Coupled to a revision system.  One cause of this is that it is
>   impossible to distribute the tests and run them without access to
>   the CVS version.  `find . -name *.[chly]' work fine without CVS
>   access.  This can be useful for beginners, or for automated testing.

Not sure what you mean by `CVS access'.
Those rules (and cvsu in particular) do not require access to
a CVS repository.  However, they do rely on the CVS/ directories
that you get any time you check out a working copy.

> In comparison, `find . -name *.[chly]' (or, of course, something
> fancier, but you'll get the idea -- it should not depend on CVS), you
> have:

As I said, it's easy to extend to cover other version control systems.

> * Easier to predict files will be tested automatically or not.

?

> * Faster (?)

IMHO, any speed difference is insignificant.

> * Works without CVS access
>
> I don't see any major disadvantages with the find-approach.  Anyone

In coreutils, I'd have to add far more exclusions,
especially for some of the generated test-related files.
More below.

> else?  An exclusion/inclusion system is required with any approach,
> and for most of my projects, the number of files to include/exclude is
> probably equal.  (Rather, I think the find-approach will cause less
> manual interventions for my projects, I have several generated source
> files that I control.)
>
>>> I'm
>>> thinking of foo.h.in and generated source code files (libidn has a few
>>> of these).  You won't get that if you only test all files in CVS.
>>>
>>> I'll go with
>>>
>>> C_SOURCE_LIST=`find . -name *.[chly]'
>>
>> That approach bothered me when I had alternate versions of code
>> sitting in my working directory not checked in.  But I suppose it's
>> worth revisiting.
>
> Explain?  Don't you want to test those versions too?  Presumably,
> these tests are only used when you are looking to fix stylistic

If I'm considering a version of a tool like fts.c and am not ready
to check it in, should I have to add exclusions for it already?
Should I check in those changes to .x-sc* files?  Of course not.

If I created a sample input file to help debug something, do
I want to be annoyed by a `make distcheck' failure because
I didn't remember to remove that file?  Definitely not.

Another problem is the length of the command line.
With coreutils, cvsu output still fits within the `...`-imposed
maximum, but `find . -type f' output is too large.

These are some of the reasons I rejected the use of a blind
`find . ...' command to generate the list of files to check.




reply via email to

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