[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rules, rules, and more (code policy) rules
From: |
Simon Josefsson |
Subject: |
Re: rules, rules, and more (code policy) rules |
Date: |
Fri, 10 Feb 2006 18:43:53 +0100 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
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.
- Re: rules, rules, and more (code policy) rules, (continued)
- Re: rules, rules, and more (code policy) rules, Jim Meyering, 2006/02/13
- 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/14
- 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 <=
- 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, 2006/02/12