Re: why is replace.mk complaining about gsed?

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Dec 10, 2011 at 08:33:18AM +0100, John Marino wrote:
> On 12/10/2011 2:42 AM, Joerg Sonnenberger wrote:
> >On Sat, Dec 10, 2011 at 01:45:14AM +0100, John Marino wrote:
> >
> >So far you have been asserting that over and over again, but haven't
> >answered Obata's question of how to reproduce it.
> 
> Obviously it's platform-specific.  The whole setup deals with
> platform specific files.  The
> fact that the doesn't see it on NetBSD means nothing.

*sigh* Which point of "how can it be replicated" is hard to understand? 
Noone said anything about NetBSD. Obata was explicitly asking about not
being able to test it on DragonFly either.


> >>An obvious possibility is that the original author screwed up by
> >>thinking defined/undefined
> >>couldn't happen when it legitimately can.
> >>To iterate:
> >>1) It's wrong to assume that replace.mk is correct and
> >>defined/undefined combo is wrong
> >You haven't provided any real evidence to support this.
> Nor have you provided the rationale that says this combination is
> impossible in good
> setup.  You took the same exact attitude about the openssl
> detection, saying that just because
> you couldn't reproduce the error then it was not worth investigating
> further.  Obviously
> that turned out to be a long-standing bug.  This pkgsrc makefile
> system is NOT bug free and the
> fact that it's used a lot time without apparent problems doesn't
> mean the report of a
> new problem is suspect.

Please stop putting words into my mouth. I never said it isn't worth
investigating further, just that I won't be the one to do it.
Surprisingly, the majority of reports *are* local problems or related to
incorrect use in specific instances. Frankly, your behavior in this
thread isn't helping your case at all, repeatable problem or not.

> >>2) Even if defined/undefined indicates a bug, it is a harmless one
> >>and preferable to a
> >>broken package.
> >I completely disagree on this. Most cases of "this is an harmless error,
> >let's silently ignore it" have created head aches in the past. Broken
> >dependencies are a good example of this. Magic workarounds without a
> >clear understanding of the code and the (supposed) bugs are just bogus.
> >They do not help.
> >
> >Joerg
> Look at the code.  In the case of sed:
> Given:
> _USE_TOOLS contains the element "g
> _TOOLS_DEPMETHOD.gsed is empty
> 
> Result of allowing empty _TOOLS_DEPMETHOD.gsed variable:
> The condition is not met and _TOOLS_DEPMETHOD.gsed remains empty.

gsed is never overwritten, so it can only be in _USE_TOOLS, if it is
also in USE_TOOLS. _TOOLS_DEPMETHOD.${TOOL} is set, if the entry for
${TOOL} is using a valid modifier. So if it ends up being empty and
_USE_TOOLS contains gsed, something is using an invalid modifier.

> If _TOOLS_DEPMETHOD.gsed being an empty string doesn't affect negatively
> any other makefile, then it's harmless (regardless if the condition
> itself is a
> bug or just some case the original author didn't consider)

How can it be harmless? It is bogus input which results in bogus
results. That's even harder to debug than finding out that it is bogus.

Joerg