tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: why is complaining about gsed?

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.


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


Home | Main Index | Thread Index | Old Index