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

[Ximin Luo]

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.

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

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

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

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.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git