Re: why is replace.mk complaining about gsed?

[John Marino <marino%netbsd.org@localhost>]

On 12/10/2011 12:22 PM, Joerg Sonnenberger wrote:
>   Frankly, your behavior in this
> thread isn't helping your case at all, repeatable problem or not.
I could have said the very same thing after your response started, "You 
are wrong.".
You could have gotten your point across with any number of alternative 
wordings that aren't inflammatory.
In that particular case, you have two functionally equivalent ways of 
doing something, so neither
is wrong.  Yours is the preferred way, and there's a difference.  The 
dislike of attitudes is mutual,
and I don't think your choice of words is accidental.


> 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.

I was able to reproduce this again.
I forgot that I modified the emacs20/Makefile to provide patches to David.
After I reverted the Makefile back to the repository version, I get this 
again.

gsed is not defined in ${USE_TOOLS} and it is defined in ${_USE_TOOLS}

Do you know how that can be possible / what can cause that?


> > 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

Well, I stand by my opinion that something like "bmake -V '${VARIABLE}' 
should never ever
result in a broken makefile message.  Once the cause of this is 
understood, a trap should be
put in place so it can spit out a warning message (and continue if 
possible).

John