[Reproducible-builds] Minimising work needed for this build-path issue
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Oct 25 15:40:38 UTC 2016
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
Thanks for laying the options out clearly, Ximin.
More information about the Reproducible-builds