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

[Simon Josefsson]

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.

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

unless someone has better ideas.

Of course, it should be possible to remove false hits easily, e.g.:

C_SOURCE_LIST_EXCLUDES=lib/doesnotcompile.h src/broken.c

The user could also manually specify the files to test:

C_SOURCE_LIST=foo.c bar.h

Thanks.