Hi all, more strict interpretations of reproducible builds want build paths to not appear in the final output *regardless of the build location* and so /tmp/build would not be appropriate. Rough justification is that we want different people building under different starting conditions to be able reproduce identical final binaries, this is a *stronger* property than reproduction under *same* starting conditions.
I believe newer versions of GCC have an existing flag called -fmacro-prefix-map: https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html My patch that Roman quoted in the email below was an additional mechanism to set -fmacro-prefix-map and -fdebug-prefix-map via an environment variable. This was not accepted into GCC because they are (in summary) allergic against using environment variables to set anything. I agree envvars are not great in general, but think an exception in this case was appropriate. It is very common for higher-level build scripts to store command-line options in various parts of the build output (making it again dependent on the build path, since the argument to -fmacro-prefix-map contains the build path). By contrast, it is almost unheard-of for tools to store arbitrary environment variables in the build output, and that usually indicates a bug. This is why we the reproducible builds project defined some standardised environment variables for these purposes: https://reproducible-builds.org/specs/source-date-epoch/ https://reproducible-builds.org/specs/build-path-prefix-map/ Inconsistently, GCC accepted our (The Reproducible Builds Project's) patch for the former but not the latter, due to different reviewers. (FWIW, the reviewer that rejected the latter patch stated that he would not have accepted the former patch.) Ed Maste (added to CC) had previously tried to get SOURCE_DATE_EPOCH accepted into LLVM but the effort seems to have stalled. https://reviews.llvm.org/D20791 https://reviews.llvm.org/D23934 I'll leave it to you guys to decide where to go from here. X Roman Lebedev: > No, that is the opposite of the solution, actually, i think. > https://tests.reproducible-builds.org/debian/issues/unstable/gcc_captures_build_path_issue.html > > And: > https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html > ^ i suspect clang should be compatible with whatever approach is > suggested there, > though i have not looked what it is. (cc'd the author of that patch here) > > On Thu, Jan 3, 2019 at 6:54 PM Nolan O'Brien <nolan.d.obr...@gmail.com> wrote: >> >> I believe reproducible build projects simply move their source to >> `/tmp/build` or something else that’s consistent to deal with `__FILE__` >> currently. They’d probably appreciate this to avoid file copying during >> `make` builds >> >> Nolan O'Brien >> Sent from my iPhone >> >>> On Jan 3, 2019, at 7:47 AM, Roman Lebedev <lebedev...@gmail.com> wrote: >>> >>> Just a thought: reproducible builds will surely be interested in this. >>> Did gcc already solve this problem? And if yes, it would be best to be >>> compatible. >>> >>> On Thu, Jan 3, 2019 at 6:41 PM Nolan O'Brien via Phabricator via >>> cfe-commits <cfe-commits@lists.llvm.org> wrote: >>>> >>>> NSProgrammer added a comment. >>>> >>>> To throw in my 2 cents. I don’t really have a preference between a >>>> compiler flag vs a different macro that’s just for the file name sans path >>>> prefix. But I have a real need for this to get into clang: with 1.2 >>>> million lines of code, the regular placement of log statements and custom >>>> asserts leads to megabytes in binary size from all the __FILE__ usages, >>>> and that could easily be a few hundred KB with this kind of support in >>>> clang. >>>> >>>> >>>> CHANGES SINCE LAST ACTION >>>> https://reviews.llvm.org/D17741/new/ >>>> >>>> https://reviews.llvm.org/D17741 >>>> >>>> >>>> >>>> _______________________________________________ >>>> cfe-commits mailing list >>>> cfe-commits@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
