Re: junk after endif

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