From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106860 invoked by alias); 4 Aug 2017 13:05:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 105960 invoked by uid 89); 4 Aug 2017 13:05:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HTo:D*debian.org X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Aug 2017 13:05:40 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63F537D0C5; Fri, 4 Aug 2017 13:05:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 63F537D0C5 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub@redhat.com Received: from tucnak.zalov.cz (ovpn-116-40.ams2.redhat.com [10.36.116.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5836360A9B; Fri, 4 Aug 2017 13:05:38 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v74D5ZRq006760; Fri, 4 Aug 2017 15:05:36 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v74D5YKA006759; Fri, 4 Aug 2017 15:05:34 +0200 Date: Fri, 04 Aug 2017 13:05:00 -0000 From: Jakub Jelinek To: Matthias Klose Cc: Jeff Law , Ximin Luo , GCC Patches Subject: Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path Message-ID: <20170804130534.GE2123@tucnak> Reply-To: Jakub Jelinek References: <20170721161538.7508-1-infinity0@pwned.gg> <3136125b-bd88-7c0b-504e-a4e4de545bbb@redhat.com> <4b6c844f-9a46-4a4b-48c5-9dfeac54b97f@pwned.gg> <7e11eaf0-99fe-e1b3-3396-df7642a56cdc@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e11eaf0-99fe-e1b3-3396-df7642a56cdc@debian.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00383.txt.bz2 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