Re: why is replace.mk complaining about gsed?

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

On Sat, Dec 10, 2011 at 01:45:14AM +0100, John Marino wrote:
> On 12/10/2011 12:46 AM, David Holland wrote:
> >On Fri, Dec 09, 2011 at 10:50:01PM +0100, John Marino wrote:
> >  >  >>That depends on what is considered the bug.  I consider comparing
> >  >  >>string variables
> >  >  >>without quotes a dodgy decision at best.  One could consider these
> >  >  >>string comparisons
> >  >  >>without double quotes to be a bug.
> >  >  >You are wrong. If the variables are allowed to be undefined, the 
> > correct
> >  >  >approach would be to use :U. Adding random "" is not what make 
> > fragments
> >  >  >should use.
> >  >
> >  >  Fine.  Would some makefile expert please fix replace.mk in the
> >  >  sanctioned way?
> >
> >I think the point is that it this combination of defined/undefined
> >shouldn't be happening, so papering it over so it doesn't fail at this
> >point is only asking for something more mysterious to go wrong.
> >
> I understand the point.
> The fact is that it is happening, and it's breaking packages.

So far you have been asserting that over and over again, but haven't
answered Obata's question of how to reproduce it.

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

> 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