Date: Mon, 6 May 2002 09:57:03 -0400 From: Antoine Beaupre <anarcat@anarcat.ath.cx> To: Max Okumoto <okumoto@ucsd.edu> Cc: The Anarcat <anarcat@anarcat.dyndns.org>, libh@FreeBSD.ORG Subject: Re: cvs commit: libh/util check_guards Message-ID: <24EE619A-60F9-11D6-B538-0050E4A0BB3F@anarcat.ath.cx> In-Reply-To: <hfhelly943.fsf@multivac.sdsc.edu>
index | next in thread | previous in thread | raw e-mail
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 majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24EE619A-60F9-11D6-B538-0050E4A0BB3F>