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

[Jim Meyering]

Simon Josefsson <address@hidden> wrote:

> A lot of the tests look like:
>
> sc_cast_of_argument_to_free:
>       @grep -E '\<free \(\(' $(srcdir)/{lib,src}/*.[chly] &&          \
>
> I.e., the paths and filenames are hardcoded.

Some are definitely tailored to the classic gnu lib,src lay-out --
or were just written a long time ago :-)
Just using $(CVS_LIST) might be better.

> 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.

> 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.

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.