Simon Josefsson <[EMAIL PROTECTED]> 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.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
