Daniel Kahn Gillmor: > On Tue 2016-10-25 08:29:00 -0400, Ximin Luo <infini...@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 = "." >> >> 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. +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. One other detail: Should we specify something about trailing '/' in oldprefix. This can be relevant when mapping directories.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds