junk after endif
Chuck Robey
chuckr at chuckr.org
Thu Apr 28 10:54:56 PDT 2005
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current
mailing list