[rb-general] rb-prefix-map spec: don't be as democratic to consumers

[Daniel Shahaf]

Ximin Luo wrote on Fri, Mar 17, 2017 at 16:09:00 +0000:
> Daniel Shahaf:
> > Ximin Luo wrote on Wed, Mar 15, 2017 at 09:24:00 +0000:
> >> Well, if I add too much text just to cater to minority cases or
> >> imagined future scenarios, other people would complain that it's too
> >> long. In the absence of a concrete suggestion I'll just leave it like
> >> it is.
> > 
> > I intentionally didn't offer a concrete suggestion, since I wanted us to
> > first agree on what the bug _was_ before agreeing on how to fix it, and
> > since there are several possible fixes and I didn't want to preëmpt the
> > discussion by writing a patch that specifies one of them.  I'd be happy
> > to come up with patches, if you wish, but I think that should come later.
> > 
> > The problem in the text is simple: how can a Makefile pass a prefix-map
> > to $(CC), without knowing what the value of $(CC) is?
> > 
> > [..]
> > 
> > As to an example, how about a project foo that has subdirectories 'bar'
> > and 'bar-addons' and then adds 
> >    ${SOURCE_ROOT_DIR}/bar=bar
> > to prefix map.  That project would be reproducible if $(CC) chooses #1
> > but not if $(CC) chooses #2.  That is, it'd be reproducible with clang
> > but not with gcc.  Do you agree that it'd be better for foo to be
> > reproducible regardless of the value of $(CC)?
> > 
> 
> I see what you mean, OK. Thanks for the example.
> 
> I would consider this a buggy producer, to only add one directory to
> the map but not the other one, even though one is responsible for both
> directories. I'll see if I can figure out a way to explain this more
> precisely. In the concept that I have, when a producer "acts
> properly", #1 and #2 would have essentially identical behaviour.

Indeed, the producer is correct with consumers that implement #1 but not
with consumers that implement #2, so it (the producer) is buggy.  My
point all along is that if the spec had not allowed consumers to choose
(between #1 and #2), it would have been impossible to write this kind of
producer bug, since all consumers would behave identically.

> > The simplest answer would be to define ONE format, "use it or you're
> > incompliant".  Anything else will lead either to coupling or to one of
> > the two choices becoming a de facto standard (and the standard thus
> > becoming a dead letter, since it says consumers can choose).
> > 
> > I think it matters less *which* format we specify as that we specify
> > *exactly one* format.  The format we specify can be #1, or it can be #2,
> > or it can be something else.
> > 
> > Also I don't think you've addressed my question of, what happens if gcc
> > chooses one behaviour, doxygen chooses another, and some project
> > Build-Depends on both of them.  (Apologies if I missed the answer)
> > 
> 
> Well, as long as they are reproducible it doesn't matter too much what
> exactly they do with the paths. I think this will be covered, once
> I specify how producers should behave more precisely, as I mentioned
> above.
> 

Okay, let's wait for the new text.

> > I think we should reach consensus on this (one way or the other) before
> > calling it 1.0.
> > 
> 
> Agreed, I'll avoid finalising this until I've sorted out this point.

Thanks.

> > [..]
> > 
> > And for what it's worth, I'm not convinced that we should let gcc
> > make this decision for us.  Having gcc be compliant with the standard
> > would certainly be a plus, but I am willing to consider the alternative
> > of writing the standard the other way and letting the gcc maintainers
> > decide whether to be non-compliant or to implement the standard we
> > invent.
> > 
> > [..]
> 
> I think if one makes up a standard and the biggest players don't
> follow it, it greatly reduces one's credibility.

Agreed: adoption by big players is an important goal.  (But not a sine
qua non)

> I will however, patch GCC to do (2) instead of (1) and see what they
> think. If they accept it, then I would be more willing to completely
> drop (1) from the specification. I think it may still be wise to say
> SHOULD instead of MUST for (2) though, partly because I'm not too
> confident about trying to reason over all possible behaviours that an
> arbitrary build tool might want to do.

Agreed.

Thanks for the detailed reply, and sorry for the delay, I had overlooked
it last Friday.

Cheers,

Daniel