Jim Meyering <[EMAIL PROTECTED]> writes: >> 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.
How many [chly] files do those macros generate? 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. In comparison, `find . -name *.[chly]' (or, of course, something fancier, but you'll get the idea -- it should not depend on CVS), you have: * Easier to predict files will be tested automatically or not. * Faster (?) * Works without CVS access I don't see any major disadvantages with the find-approach. Anyone 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 problems. I'm not sure they should run automatically. Perhaps on 'make dist', but in that case I think it is a bad idea to have alternate versions of code laying around. Hm. But I get your point. If a developer often keep unrelated code in the directories, they will interfere. I don't work that way, so I wouldn't have thought of that. > 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. Agreed. Thanks. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib