Date: Thu, 28 Apr 2005 17:54:39 +0000 From: Chuck Robey <chuckr@chuckr.org> To: Scott Long <scottl@samsco.org> Cc: Harti Brandt <harti@freebsd.org> Subject: Re: junk after endif Message-ID: <4271235F.1070609@chuckr.org> In-Reply-To: <42710AD1.9010602@samsco.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4271235F.1070609>