[Top][All Lists]
[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.
- Re: rules, rules, and more (code policy) rules, (continued)
- Re: rules, rules, and more (code policy) rules, Jim Meyering, 2006/02/14
- Re: rules, rules, and more (code policy) rules, Simon Josefsson, 2006/02/14
- Re: rules, rules, and more (code policy) rules, Simon Josefsson, 2006/02/16
- Re: rules, rules, and more (code policy) rules, Jim Meyering, 2006/02/17
- Re: rules, rules, and more (code policy) rules, Simon Josefsson, 2006/02/11
- Re: rules, rules, and more (code policy) rules, Jim Meyering, 2006/02/12
- Re: rules, rules, and more (code policy) rules, Simon Josefsson, 2006/02/13
Re: rules, rules, and more (code policy) rules, Simon Josefsson, 2006/02/10
- Re: rules, rules, and more (code policy) rules, Jim Meyering, 2006/02/10
- Re: rules, rules, and more (code policy) rules, Simon Josefsson, 2006/02/11
- Re: rules, rules, and more (code policy) rules,
Jim Meyering <=