Re: cvs commit: libh/util check_guards

Le Lundi 6 mai 2002, à 04:27 , Max Okumoto a écrit :

>
> In previous projects that I have worked on the people have
> created header files by coping old header files.

Quite a bad idea, if you ask me.

> When using
> guards, it is really hard to trace down when someone forgets
> to update the tag.  So I wrote this to scan the headers and
> create tags from the names of the files.   The script would
> just replace any tag that was already protecting the file.
> If and only if three tags in the guard matched.

A good idea, so far.

> 	Bar.hh -> Bar_hh
>
> On really large projects different programmers have named files
> with the same name.  They are in different lib hence had different
> paths.  So I added protection by adding the md5
>
> 	include/Dance/Bar.hh -> Bar_hh_a6507158
> 	include/Sing/Bar.hh ->  Bar_hh_12343435

Which I consider overkill, but an interesting feature.

Although I'm not sure that a 8 character MD5 string is "as unique" as 
the full string. We might end up creating similar header guards, however 
unlikely. :)

> Thus if a file musical.cc had the following includes
> 	#include "Dance/Bar.hh"
> 	#include "Sing/Bar.hh"
>
> The two header files would not exclude the other if the tag
> was only Bar_hh.

The problem I had with that scheme is that it is not useful in the 
current "flat compilation directory" scheme we are using. It is very 
likely that Dance/Bar.hh and Sing/Bar.hh are associated with 
Dance/Bar.cc and Sing/Bar.cc, which will both end up as 
compile/$UITYPE/Bar.o, which will also be very hard to track down.

I think the project is not yet big enough that we don't know exactly 
which header files we have, especially now they're all in include/.

It's still a nice feature to have, especially since we can modify the 
code to make the MD5 optional, but I don't think it should be part of 
the regular builds, just as a helper tool when something goes wrong, and 
in that case, I'd rather have the script *detect* similar header 
file/guards and let us deal with it in a proper manner than just run 
find -exec over the whole tree.

It's good you explain all this, but before you did that I had to figure 
it out by looking at the code. The commit log should have told me 
that. :)

A.


To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-libh" in the body of the message