Simon Josefsson <[EMAIL PROTECTED]> wrote: > 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.
Not sure what you mean by `CVS access'. Those rules (and cvsu in particular) do not require access to a CVS repository. However, they do rely on the CVS/ directories that you get any time you check out a working copy. > In comparison, `find . -name *.[chly]' (or, of course, something > fancier, but you'll get the idea -- it should not depend on CVS), you > have: As I said, it's easy to extend to cover other version control systems. > * Easier to predict files will be tested automatically or not. ? > * Faster (?) IMHO, any speed difference is insignificant. > * Works without CVS access > > I don't see any major disadvantages with the find-approach. Anyone In coreutils, I'd have to add far more exclusions, especially for some of the generated test-related files. More below. > 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 If I'm considering a version of a tool like fts.c and am not ready to check it in, should I have to add exclusions for it already? Should I check in those changes to .x-sc* files? Of course not. If I created a sample input file to help debug something, do I want to be annoyed by a `make distcheck' failure because I didn't remember to remove that file? Definitely not. Another problem is the length of the command line. With coreutils, cvsu output still fits within the `...`-imposed maximum, but `find . -type f' output is too large. These are some of the reasons I rejected the use of a blind `find . ...' command to generate the list of files to check. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib