From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:13:24 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 0C50416A4CF; Thu, 28 Apr 2005 16:13:24 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BAFD43D3F; Thu, 28 Apr 2005 16:13:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j3SGHZEH023934; Thu, 28 Apr 2005 10:17:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42710AD1.9010602@samsco.org> Date: Thu, 28 Apr 2005 10:09:53 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harti Brandt References: <4270762E.3050508@chuckr.org> <20050428164808.X821@beagle.kn.op.dlr.de> <4270FA78.6030406@samsco.org> <20050428170600.L821@beagle.kn.op.dlr.de> In-Reply-To: <20050428170600.L821@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Chuck Robey cc: current 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 16:13:24 -0000 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 > 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. > > Regards, > harti Thanks a lot! Scott