From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 17:54:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27C9616A4CF; Thu, 28 Apr 2005 17:54:56 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31A243D48; Thu, 28 Apr 2005 17:54:54 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from [66.92.151.195] (july.chuckr.org [66.92.151.195]) by april.chuckr.org (Postfix) with ESMTP id 1994F1213F; Thu, 28 Apr 2005 13:50:20 -0400 (EDT) Message-ID: <4271235F.1070609@chuckr.org> Date: Thu, 28 Apr 2005 17:54:39 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4270762E.3050508@chuckr.org> <20050428164808.X821@beagle.kn.op.dlr.de> <4270FA78.6030406@samsco.org> <20050428170600.L821@beagle.kn.op.dlr.de> <42710AD1.9010602@samsco.org> In-Reply-To: <42710AD1.9010602@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current cc: Harti Brandt Subject: Re: junk after endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 17:54:56 -0000 Scott Long wrote: > Harti Brandt wrote: > >> On Thu, 28 Apr 2005, Scott Long wrote: >> >> SL>Harti Brandt wrote: >> SL>> On Thu, 28 Apr 2005, Chuck Robey wrote: >> SL>> SL>> CR>in making the environment for my new sparc box, I'm >> building a new >> SL>> buildworld >> SL>> CR>for the sparc, that that's giving me REAMS of useless errors >> about "junk >> SL>> at >> SL>> CR>the end of the line", you know what it is from watching the >> error come >> SL>> up >> SL>> CR>from cpp listings...except that these come from make, not from >> C code... >> SL>> CR>having this come up in the situation I'm in, with zero >> (besides merely a >> SL>> CR>KERNCONF) in the /etc/make.conf, then having this error come >> up so often >> SL>> it >> SL>> CR>obscures the real listing is egregiously crazy. >> SL>> CR> >> SL>> CR>So, the fix falls into one of these categories: >> SL>> CR> >> SL>> CR>1) there is a magic incantation I don't know, and don't have >> time to >> SL>> hunt >> SL>> CR>down, that kills this warning in make, and I need to know >> this, but >> SL>> that's >> SL>> CR>not the fix ... the fix is (possibly) to make the default >> action that >> SL>> this is >> SL>> CR>NOT a warning. >> SL>> CR> >> SL>> CR>2) I know that many folks like to do this to endif's, but it's an >> SL>> warning in >> SL>> CR>C, and we should tell the folks who like it "tough" and take >> them out. >> SL>> CR> >> SL>> CR>However it's decided, to squish the warning or to squish the >> tags, it's >> SL>> CR>unacceptable to leave those semantically useless warnings >> laying about, >> SL>> CR>hiding real problems. >> SL>> SL>> These warnings come only if you build with a /usr/share/mk >> which is not >> SL>> up-to-date and an up-to-date make. (It may also be that you >> slipped with >> SL>> your sources into the small window between the two commits). >> SL>> SL>> As far as I can see this can legally happen only when >> building 5.4 or >> SL>> earlier on a current box (I have committed the fix to >> /usr/share/mk in >> SL>> RELENG_5, but cannot do this because this doesn't seem to fall >> under the >> SL>> committable categories for RELENG_5_*). >> SL>> SL>> harti How did it happen? I used the most recent 5.3 cdrom images to install from, then used RELENG_5_4 as a -r to cvs when I pulled out sources to rebuild from. This is NOT an odd combination, rather it's going to be a pretty common one pretty soon. >> SL> >> SL>In general, I think that this warning is a bad idea. It (along >> with the >> SL>NO_FOO wanrings that are also a bad idea) make it very hard to build >> SL>prior releases and snapshots from 6-current. I really cannot see how >> SL>this warning benefits anyone or solves a problem; all it does it >> create >> SL>an unneccesary mess. Yes, building things like I've described here >> SL>isn't "supported", but putting up needless roadblocks and making the >> SL>definition of "supported" be very narrow makes using FreeBSD very >> hard. >> SL>Please eliminate this warning, or put it under a 'pendatic' flag only. >> >> I found at least one incarnation of an expression after an .else in a >> port Makefile where the writer obviously expected the expression to be >> processed. The problem was that the author wrote .else instead of >> .elif. We found also a number of incarnations of .elseif statements >> that make silently happend to process as .else. Makefiles are >> inherently hard to debug (because of the crufty syntax and the >> sloppiness of our make), so every warning maybe helpful. I agree that >> this should be under the control of an option and, in fact, I was >> going to implement just that - its just not that high on my list. But >> as you ask so nicely about it I can move it up the list and do it in >> the next days. Good, I personally believe the warning has very little value. >> >> Regards, >> harti > > > Thanks a lot! > > Scott > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"