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>
next in thread | previous in thread | raw e-mail | index | archive | help
Le Lundi 6 mai 2002, =E0 04:27 , Max Okumoto a =E9crit : > > 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=20 the full string. We might end up creating similar header guards, however=20= 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=20 current "flat compilation directory" scheme we are using. It is very=20 likely that Dance/Bar.hh and Sing/Bar.hh are associated with=20 Dance/Bar.cc and Sing/Bar.cc, which will both end up as=20 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=20 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=20 code to make the MD5 optional, but I don't think it should be part of=20 the regular builds, just as a helper tool when something goes wrong, and=20= in that case, I'd rather have the script *detect* similar header=20 file/guards and let us deal with it in a proper manner than just run=20 find -exec over the whole tree. It's good you explain all this, but before you did that I had to figure=20= it out by looking at the code. The commit log should have told me=20 that. :) A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24EE619A-60F9-11D6-B538-0050E4A0BB3F>