From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [gnu-prog-discuss] Reproducible builds Date: Mon, 21 Dec 2015 22:32:47 -0500 Message-ID: References: <1450695354.3591.18.camel@invergo.net> <1450710479.31597.40.camel@Renee-desktop.suse> <87r3ifkepm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1450755211 15907 80.91.229.3 (22 Dec 2015 03:33:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 03:33:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: ludo@gnu.org (Ludovic =?windows-1252?Q?Court=E8s?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 04:33:21 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aBDhP-0001PM-P5 for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 04:33:19 +0100 Original-Received: from localhost ([::1]:48519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBDhP-0005QB-3r for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 22:33:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBDhC-0005Pv-RX for emacs-devel@gnu.org; Mon, 21 Dec 2015 22:33:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBDhB-0000HT-OO for emacs-devel@gnu.org; Mon, 21 Dec 2015 22:33:06 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:50939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBDh7-0000Gg-95; Mon, 21 Dec 2015 22:33:01 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id tBM3Wswc030617; Mon, 21 Dec 2015 22:32:55 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 298EAAE49C; Mon, 21 Dec 2015 22:32:48 -0500 (EST) In-Reply-To: <87r3ifkepm.fsf@gnu.org> ("Ludovic =?windows-1252?Q?Court=E8s?= =?windows-1252?Q?=22's?= message of "Mon, 21 Dec 2015 16:23:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered TRK_NCM1=0.2, RV5527=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5527> : inlines <4139> : streams <1558110> : uri <2106142> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196635 Archived-At: BTW, in https://reproducible.debian.net/index_issues.html I fail to see one issue that should affect Emacs: the result depends on ordering of independent commands. So in sequential builds, this does not manifest itself, but in parallel builds the result becomes non-deterministic. The way this shows up in Emacs is that depending on how the byte-compilations get ordered, all the (require ') will either load the corresponding .el or the .elc. In many cases, the end result is 100% identical, but if .el includes functions defined with defsubst then the result can be different because in one case the defsubst's source will be inlined and in the other the defsubst's byte-code will be inlined. The easiest way to solve this problem is probably to get rid of the "source-level inlining". IIRC this is already partly the case for lexical-binding reasons: we can't inline (at the source-level) lexical-binding code in dynamic-binding code (nor vice versa), so when the binding style disagrees we forcefully byte-compile the defsubst to make sure the inlining is done on the byte-code (where the binding-style is not a problem any more). So we could simply always forcefully byte-compile the defsubst, even when the binding styles agree. Of course, there can be other differences depending on all kinds of weird tings you can do with eval-when-compile and friends, but in practice this should hopefully never be an issue. Still, it would be good to *test* that there aren't other such issues. We could also reduce/eliminate those problems by adding dependencies in the makefile so that (require ') always gets the .elc file, but this would reduce the available parallelism during compilation, and it's hard to do in general: many packages have circular requires. Stefan