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

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

Special-casing on each possible value of $(CC) isn't a satisfactory
solution because it's not forward compatible with future (as yet
unwritten) compilers used to compile the current release.

This isn't really a problem for distros because they compile everything
with the same $(CC), nor for people who reproduce old binaries (because
of the bug-for-bug-compatibility requirement discussed upthread); it's
only a problem for upstream maintainers, because when they release
a foo-1.0.tar.gz package they need it to work with all versions of all
popular compilers (gcc, clang, solaris, windows, ...).

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

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)

I think we should reach consensus on this (one way or the other) before
calling it 1.0.

Cheers,

Daniel

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.