Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Or in compile and link time?
>
| Ouch!
>
>> What we could do is to make these scripts (in particular if some of
>> them does not need human intervention to be correct) is to make a
>> "test" target that tests the source tree:
>>
>> - make sure that all .C files includes config.h
>
| Trivial:
| $ find . -name "*.C" | while read file; do grep '^ *# *include *<config\.h>'
| $file > /dev/null && continue; echo $file 'does not #include <config.h>!';
| done
| ./graph.C does not #include <config.h>!
| ./support/gzstream.C does not #include <config.h>!
And then we need a list of files where this is ok.
>> - make sure that all files has the correct header blurb
>
| I've done that over the last few weeks and months. I think that all
| are now up to data. Simple test:
Sure, I think you have caught all cases. What this "make test" would
be for is _new_ changes to CVS, so that we catch "regression" like
this early.
>> - looks for unneeded using statements
>
| I wrote and posted a script that automates this to some extent. It's greedy in
| that it will automatically remove things inside deactivated macro blocks, but
| it is relatively easy to go through the diff file and put things back. This
| is exactly what I did last night. For two hours.
For "make test" I don't want anything automatically removed, just
flagged, and we must have a file telling the scripts that "this
particular item should not be flagged"
>> - looks for unneeded include statements
>
| Ditto. The point to note is that these last two are not painless. Nonetheless,
| I think that the source is now in a sufficiently clean state that they won;t
| be needed for some time to come.
That is why "make test" would be ok. To that we don't unknowingly
regress.
(make test or make check... I don't care)
--
Lgb
