From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in Date: Sun, 14 Apr 2019 13:30:50 -0400 Message-ID: References: <59835b95-50e3-4e8e-b116-ae3915aef875@email.android.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72483"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: dancol@dancol.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 14 19:31:46 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hFiym-000Ii2-1p for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 19:31:44 +0200 Original-Received: from localhost ([127.0.0.1]:38230 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFiyl-0004EH-2b for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 13:31:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFixz-0004E3-KJ for emacs-devel@gnu.org; Sun, 14 Apr 2019 13:30:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFixy-0003zC-M7 for emacs-devel@gnu.org; Sun, 14 Apr 2019 13:30:55 -0400 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:15587) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1hFixw-0003w4-4q; Sun, 14 Apr 2019 13:30:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FOIgD7bLNc//zyd0tmHAEBAQQBAQcEA?= =?us-ascii?q?QGBZYIRJ0FRIRIoh1hohEmKLoIMEyIBgXsBmBEQG4EWgzYEAgKFdiQ4EwEDAQE?= =?us-ascii?q?BCQEBAQECAgJpHAyEL18+AQQBViMFCws0EhQYDYNagXkPqmuDdYYygTKLYYF/h?= =?us-ascii?q?CM+hRGFFAOKVZtdCYIHhgmMKIJliGyJIo05jn2DZwyBZiKBVjMaCDA7gmwJglC?= =?us-ascii?q?FdogZJjCQcgEB?= X-IPAS-Result: =?us-ascii?q?A2FOIgD7bLNc//zyd0tmHAEBAQQBAQcEAQGBZYIRJ0FRIRI?= =?us-ascii?q?oh1hohEmKLoIMEyIBgXsBmBEQG4EWgzYEAgKFdiQ4EwEDAQEBCQEBAQECAgJpH?= =?us-ascii?q?AyEL18+AQQBViMFCws0EhQYDYNagXkPqmuDdYYygTKLYYF/hCM+hRGFFAOKVZt?= =?us-ascii?q?dCYIHhgmMKIJliGyJIo05jn2DZwyBZiKBVjMaCDA7gmwJglCFdogZJjCQcgEB?= X-IronPort-AV: E=Sophos;i="5.60,350,1549947600"; d="scan'208";a="90522866" Original-Received: from 75-119-242-252.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([75.119.242.252]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2019 13:30:50 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 3DC29AE526; Sun, 14 Apr 2019 13:30:50 -0400 (EDT) In-Reply-To: <59835b95-50e3-4e8e-b116-ae3915aef875@email.android.com> (dancol@dancol.org's message of "Sun, 14 Apr 2019 08:47:42 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.38 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:235451 Archived-At: > The fingerprint is not guaranteed foolproof when computed from the *.o > files and is not guaranteed foolproof when made from the temacs.in > file either. > > Isn't it? I don't see anything in the semantics of `ld` which makes the guarantees we'd need, no. Maybe current `ld` does, in practice, of course. > The two approaches are not equally robust. No, indeed. > The temacs.in approach is as close as you're going to get to foolproof > and future proof. Might be. Actually backpatching the fingerprint into `temacs` might be in some cases more robust (it doesn't assume that both runs of `ld` produce the same result). But my point is just that it's a question of degree. Just like the compilation time is a question of degree. Noone is wrong or right here, these are just personal preferences. I use machines whose age spans between 16 and 5 years (my main work laptop is more than 10 years old because it's more or less the most recent 4:3 I could find) so I value speed ups in compilation time probably more than others on this list. Stefan