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

[Simon Josefsson]

Jim Meyering <address@hidden> writes:

>> Using 'find . -name *.[chly]` seem more appropriate.  Or?
>>
>> Some tests do:
>>
>> sc_space_tab:
>>      @( $(CVS_LIST) ) > /dev/null 2>&1 || : &&                       \
>>
>> where CVS_LIST is:
>>
>> # cvsu is part of the cvsutils package: http://www.red-bean.com/cvsutils/
>> CVS_LIST = $(srcdir)/build-aux/cvsu --find --types=AFGM
>>
>> This has the problem of being tied to cvs.  Even if that could be
>> fixed, I'm not sure there is any advantage over the above solution.
>> Sometimes testing generated source code files is useful too.
>
> It's useful if you `own' the tool that does the generating or otherwise
> contributes the violation.  But if you don't (autoconf, automake, some
> .m4 macro), then it's just annoying.

How many [chly] files do those macros generate?

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.

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

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

* Faster (?)

* Works without CVS access

I don't see any major disadvantages with the find-approach.  Anyone
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
problems.  I'm not sure they should run automatically.  Perhaps on
'make dist', but in that case I think it is a bad idea to have
alternate versions of code laying around.

Hm.  But I get your point.  If a developer often keep unrelated code
in the directories, they will interfere.  I don't work that way, so I
wouldn't have thought of that.

> I suggest you rewrite it to look like this instead:
>
>   C_SOURCE_LIST = $(find . -name *.[chly])
>
> Using $(...), such a variable can be expanded e.g.,
> within `...`, and you don't have to worry about double quotes.
> And spaces around the `=' make it a little more readable, imho.

Agreed.

Thanks.