<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="de" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title></title><style type="text/css">html,body{background-color:#fff;color:#333;line-height:1.4;font-family:arial, helvetica, sans-serif;;}</style></head><body><p>Hi all</p>
<p>I'm not sure whether it's the correct topic, but I will contribute two things:</p>
<p>a) The build process should be well documented and obviously. It means usage of an environment variable inside the compiler, internal, it very bad for that. Because the value of the envvar may be unknown after build. It is possible to use an environment variable as argument : gcc ... $SPECIALOPTION but the expanded value should be documented. A good idea is documentation of the effective command line, may be by an echo statement. </p>
<p>b) Absolute Paths on build: I have the experience that the absolute path is stored in Objectfiles while compiling and influences the machinen code, unexpected and unfortunatelly, but it was so on some compiler. My solution in this kind was: Re-Compiling under same conditions of absolute paths, storing the "Sandbox" of sources in the same absolute path on any machine. A symbolic link on Unix is helpfull. Because I had need do that on a Windows PC (XP), I have used the subst command: "subst B: D:\my\special\path" and start the compilation from "B:\localmake". Hint: On Windows the B-drive was a diskette in the old past, it is usual free to use. </p>
<p> </p>
<div ></div>
<p>Vagrant Cascadian schrieb am 26.06.2020 02:27 (GMT +02:00):</p>
<blockquote cite="mid:87pn9macxt.fsf@ponder">
<pre>On 2020-06-26, Bill Allombert wrote:
> Is it possible to set -fdebug-prefix-map via an environment variable or
> a similar mechanism rather than through the command line ?
>
> The issue is that adding -fdebug-prefix-map=PREFIX to CFLAGS
> leads to PREFIX leaking in buildlogs and in generated Makefiles and
> similar files that can end up inside packages, making previously
> reproducible packages unreproducible.
We had proposed BUILD_PATH_PREFIX_MAP to address exactly these kinds of
issues:
<a href="https://reproducible-builds.org/specs/build-path-prefix-map/" target="_blank" rel="nofollow noopener" title="https://reproducible-builds.org/specs/build-path-prefix-map/">https://reproducible-builds.org/specs/build-path-prefix-map/</a>
Unfortunately it was not accepted into upstream GCC as they did not like
accepting input from an environment variable (yes, they let
SOURCE_DATE_EPOCH slip though!) ... not sure if many or any other
compilers have adopted it.
It would be good to revisit at some point if there is any way we could
conceivably get GCC developers on board with some variant of the
proposal. Maybe try getting into other toolchains first?
My best thought was --build-path-from-env=BUILD_PATH_PREFIX_MAP to at
least make it explicity as to which environment variable was affecting
behavior, without embedding the value of the environment variable in the
commandline... but I didn't get positive feedback on this approach back
when I presented at GNU Tools Cauldron last year and floated the idea.
live well,
vagrant
</pre>
</blockquote></body></html>