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

[HW42]

Ximin Luo:
> Hi all,
> 
> I'm thinking of ways to minimise the work needed to fix the build path
> issues that we're having.
> 
> The present method is that dpkg-buildflags sets
> "-fdebug-prefix-map=$PWD=." into various *FLAGS envvars, and Make (or
> another build tool) will pass this to gcc. This works if and only if
> the package uses dpkg-buildflags, which granted is most of them.
> 
> However, I am not sure if this is the best approach. At present, the
> output of dpkg-buildflags is itself dependent on the build-path, and
> some packages *might* save this value somewhere in their output. (This
> is the case for perl, although in perl's specific case this seems
> fixable.)
> 
> However the question is, do we want to do this every time an upstream
> saves CFLAGS somewhere?
> 
> It is after all a part of the "reasonable" build input - i.e. it is
> reasonable that whatever is in CFLAGS will affect the build output, so
> saving it in arbitrary ways isn't an "unreasonable" thing for upstream
> packages to do. We will have to educate everyone "please filter out
> debug-prefix-map from CFLAGS before you save it somewhere" and this
> adds extra complexity to the whole ecosystem.
> 
> So, here are some other approaches:
> 
> 1. Patch GCC to set debug-prefix-map to "$pwd=." by default (and the
> analogue for other languages / tools).
> 
> This behaviour is concretely different from the current situation:
> during recursive-make scenarios, the gcc in subdirectories will have
> different values for debug-prefix-map. Our current situtation OTOH is
> that dpkg-buildflags is called once at the top-level directory, and
> this value persists for all gcc subchildren for the whole build
> (unless the upstream buildscripts do something weird to CFLAGS).
> 
> If the behaviour were not different, I would strongly suggest "let's
> just do this". But it's different, and I'm not sure what consequences
> that would have. I'm looking for your comments on this.

I think this breaks the mapping to the source file, for example in gdb.
So I think this is not a good solution.

> Note that for languages that define "the path is the namespace" like
> golang or java, this does not really matter. So in these cases I
> strongly suggest patching the tool itself, instead of adding extra
> command-line flags.

Could you clarify what you mean? I don't think the namespace and the
path are the same in golang or in Java (sure, the namespace is the
suffix of the path but including java.nio.file.Path into the binary
doesn't break any of our assumptions).

> 2. Define another variable SOURCE_ROOT to be set to the top-level
> source dir, and patch GCC to use this as the default value for
> debug-prefix-map (and the analogue for other languages / tools).
> 
> This would have the same concrete behaviour as the current situation,
> but then we're defining yet another variable... but probably less
> tools will need to support this than SOURCE_DATE_EPOCH. And as with
> (1), this would not be necessary for the path-is-namespace languages.
> 
> X

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 825 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160824/6b9f9c5e/attachment.sig>