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

[Ximin Luo]

HW42:
> Daniel Kahn Gillmor:
>> On Tue 2016-10-25 08:29:00 -0400, Ximin Luo <infinity0 at debian.org> wrote:
>>> Option A
>>>
>>> oldprefix = getenv("SOURCE_ROOT_DIR")
>>> newprefix = getenv("SOURCE_ROOT_PREFIX") or "."
>>>
>>> Pros: Simple, easy to understand. Works almost exactly as
>>> debug-prefix-map which has already existed for ages in GCC.
>>> Cons: Uses two environment variables.
>>>
>>> Option B
>>>
>>> oldprefix, newprefix = getenv("SOURCE_PREFIX_MAP").split("=", 1)
>>>
>>> Pros: Works *exactly* as debug-prefix-map
> 
> SOURCE_PREFIX_MAP is less like to colide with existing usage than
> SOURCE_ROOT_DIR.
> 
>>> Cons: Have to parse the thing. GCC splits on the first "=" but I
>>> found this out by looking at the source code
>>> (gcc/final.c:add_debug_prefix_map), it's not explicitly documented.
>>> Someone else could split at the last "=" for example.
>>
>> While i think A would be simpler in a perfect world with no history, i
>> think i prefer B here.
> 
> I would prefer A because it saves consumer from parsing and makes the
> spec a bit shorter/simpler but I'm fine with both.
> 
>> We'll be documenting this, so we can simply define which "=" character
>> we split on.  I'd even be fine with saying that we don't allow "=" in
>> either path, fwiw, if it makes things easier.
>>
>> B has the advantages of being able to justify it with reference to
>> known, existing functionality (debug-prefix-map) and the environment
>> variable name is clearer (none of the "ROOT" ambiguity).
>>
>>> Option C
>>>
>>> oldprefix = getenv("ALLSOURCES_DIR")
>>> newprefix = "."
>>>
>>> [..]
>>
>> This also makes it harder to do a reproducible build from a VCS
>> checkout, fwiw, if the build path is going to have the version number in
>> it.  the VCS checkout is likely to just be in $PACKAGENAME, and having
>> to rename it to $PACKAGENAME-$VERSION just to do the build seems weird
>> and potentially problematic.  We want it to be easy to reproduce, with
>> minimal hoop-jumping.
> 
> +1
> 
> There are also other useful cases in which a choosable prefix helps.
> For example when you build stuff without unique version numbers you
> could use something like:
> 
>   newprefix = mypackage-$(git rev-parse --verify HEAD^{})
> 
> So I think we should keep the arbitrary choosable prefix.
> 

Alright, so we can drop option C. It was mostly for illustrative and "inspirational" purposes.

So, I can implement option B fairly easily, but there is one ugly fact about the syntax that we should think about. The way that GCC does it, it means you can't strip a prefix that itself contains the "=" character.

Now this is not going to matter in all the cases that *we* want to use it for. Doing a `sudo find / -name "*=*"` on my system gets me one result: "songs/releases/2012 - Grimes - Visions/06 Vowels = space and time.mp3".

However, we're defining a *standard* here and if it takes off, it will last for quite some time and have quite wide reach. It means that if someone wants to have a folder structure like e.g.

C:\Documents and Settings\Betrand Russell\Proofs of 1+1 = 2\Automated Proofs\Source Code\

or perhaps in the future:

/srv/net/distributed-hash-table/address/VaIWP8YIWDChR2O76yiufXBsbw5g2skB/kp9VP+qVLvydovdGw==/projects/gcc-6/

these people won't be able to use this standard. Do we care about these sorts of things? Even if not, we should explicitly say "Paths containing '=' are not supported" - there is no sense in trying to brush this fact "underneath the carpet".

> 
> One other detail: Should we specify something about trailing '/' in
> oldprefix. This can be relevant when mapping directories.
> 

Did you have a specific example in mind? I think the current behaviour is fine, especially if we support the arbitrary newprefix: if you give it "/build/pkg/=." then you'll end up with paths like ".src/blah.c", but if you give it "/build/pkg/=" then the result is fine.

X

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