[Reproducible-builds] Minimising work needed for this build-path issue

[Ximin Luo]

HW42:
> Daniel Kahn Gillmor:
>> On Tue 2016-09-06 16:02:00 -0400, Ximin Luo wrote:
>>> Thanks, I did see this a while ago and forgot about it. However it
>>> does differ from the current proposal in an important way.
>>>
>>> Current proposal (2): GCC should, if SOURCE_ROOT is set and
>>> debug-prefix-map is not given, *automatically* use this
>>> variable. There is no opportunity for the user to tell GCC to look at
>>> a different variable.
>>>
>>> OTOH your patch above has GCC read a user-supplied variable. I think
>>> we want to avoid this, for the same reason that we pushed quite
>>> heavily for upstreams to support SOURCE_DATE_EPOCH and not their own
>>> custom command line option. It would also fix packages using gcc but
>>> not dpkg-buildflags (and for other distros, etc).
>>
>> ah, right.  I like your constrained version better; hard-coding sensible
>> practices helps keep everyone on the right track.  It's also much
>> simpler to argue for this approach if we can point to how
>> SOURCE_DATE_EPOCH is already supported.
>>
>> bikeshedding: is SOURCE_ROOT the right name?  I worry a bit about the
>> different possible meanings of "ROOT" on unix systems.  maybe
>> SOURCE_BASE_DIR or SOURCE_DIR_ROOT is more descriptive of what we are
>> describing?  No strong preferences on my side.
> 
> I think we should also try to choose a name which is not already used by
> other build systems or similar things.
> 
> According to codesearch.d.n it seems only SOURCE_DIR_ROOT isn't taken
> yet. (Google finds at least one case).
> 
> also bikeshedding: I dislike SOURCE_DIR_ROOT because the name is some
> how redundant. What's the difference between SOURCE_DIR and
> SOURCE_DIR_ROOT? But I don't care much about the naming.
> 

I have prepared the GCC patches, they are here:

https://gist.github.com/infinity0/72aba22411a2e8baaae4649329f96643

But before I start submitting them to GCC, let's see if we can work out this final point:

>>> But for sure we can start from the code that you already wrote. :)
>>
>> yep, that's what i was proposing; i certainly don't mean to suggest that
>> my original patch is the thing that should be adopted.
> 
> Btw: Do you know why currently debug-prefix-map maps the source dir to
> '.'? (My guess is because that's the easiest in dpkg-buildflags) I think
> for debugging between package boundaries '${srcpkg}-${srcver}' would be
> much better.
> 
> So maybe a MAP_SOURCE_PATHS variable would be better. But this has the
> big disadvantage of making things more complex.
> 

I think this idea is good in principle and we should try to aim for it. My preference would be to have a second environment variable though, e.g. SOURCE_ROOT_PREFIX.

I think combining both of these envvars into one single envvar of the form "$source=$target", though it matches the syntax for -fdebug-prefix-map, would make it harder for other programs and build tools to adopt as a standard.

What do you (all) think?

X

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