From owner-freebsd-libh Mon May 6 7: 4:44 2002 Delivered-To: freebsd-libh@freebsd.org Received: from mail1.qc.uunet.ca (mail1.qc.uunet.ca [198.168.54.16]) by hub.freebsd.org (Postfix) with ESMTP id 02B0F37B421 for ; Mon, 6 May 2002 07:04:28 -0700 (PDT) Received: from Xtanbul ([216.94.147.34]) by mail1.qc.uunet.ca (8.10.2/8.10.2) with ESMTP id g46E4Dj17884; Mon, 6 May 2002 10:04:13 -0400 Date: Mon, 6 May 2002 09:57:03 -0400 Subject: Re: cvs commit: libh/util check_guards Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: The Anarcat , libh@FreeBSD.ORG To: Max Okumoto From: Antoine Beaupre In-Reply-To: Message-Id: <24EE619A-60F9-11D6-B538-0050E4A0BB3F@anarcat.ath.cx> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.481) Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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