On Fri, Aug 04, 2017 at 08:32:33AM -0400, Matthias Klose wrote: > >> GCC already supports a similar environment variable SOURCE_DATE_EPOCH, > >> which was accepted about 2 years ago in a patch written by one of our GSoC > >> students. We are not planning any more environment variables like this, > >> and are committed to fixing other sources of non-determinism by patching > >> the relevant build scripts. > > I would have rejected that as well :-) One of the few times I would > > have disagreed with Bernd. > > You can argue that gcc has command line options to set these, but most build > systems can be influenced by well documented environment variables like > CFLAGS, > CXXFLAGS, LDFLAGS, so adding one more variable like SOURCE_DATE_EPOCH makes > sense, considering that many tools dealing with timestamps don't even have > command line options to do these (and there it's not just about compilers).
Unlike SOURCE_DATE_EPOCH, the other env vars are autoconf/cmake etc. related, we really shouldn't be adding more of these. If some package has messed up build system, you can use CXX='g++ -fwhatever' or whatever other way to pass flags you want to the compiler or pick the compiler you prefer to use. > BUILD_PATH_PREFIX_MAP might be passed as well in CFLAGS / CXXFLAGS, but there > are build systems that even ignore these environment variables, and it's > common > to require the use of environment variables for distributions, like > > http://pkgs.fedoraproject.org/cgit/rpms/gcc.git/tree/gcc7-foffload-default.patch Dunno how this patch is related to the env var vs. command line option question, the env var in the patch is used to communicate stuff from the gcc driver to subcommands. It isn't something users should be using on their own. Jakub
