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

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

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 = "."
>
> Oh em gee what is going on here? Well this is a slight hack. Instead of setting SOURCE_ROOT_DIR=/build/blahblah we set ALLSOURCES_DIR=/build so that "blahblah" remains in the build output. This is analogous to the difference between "datadir = /usr/share/@PACKAGE@" vs "datarootdir = /usr/share" (in GNU installation directories naming conventions).
>
> Pros: Simple for implementers, one environment variable that doesn't have to be parsed.
> Cons: Requires reproducers to do the build in a directory called "blahblah". At least, everyone can do this - if you can't create directories with arbitrary names, you probably can't set environment variables either. However it does mix up two different mechanisms (env var + directory naming) to achieve reproducibility.

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.

Thanks for laying the options out clearly, Ximin.

    --dkg