From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Native compilation: the bird-eye view Date: Sun, 23 Aug 2020 14:20:06 -0400 Message-ID: References: <83o8qocd32.fsf@gnu.org> <83blmndbpo.fsf@gnu.org> <838shrdb1c.fsf@gnu.org> <837dxbd93b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33344"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , Paul Eggert , "Andrea Corallo via Emacs development discussions." To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 23 20:20:45 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9ubk-0008bM-S0 for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Aug 2020 20:20:44 +0200 Original-Received: from localhost ([::1]:53628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9ubj-0001PN-JW for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Aug 2020 14:20:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9ubG-0000wP-AM for emacs-devel@gnu.org; Sun, 23 Aug 2020 14:20:14 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23231) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9ubD-00054X-Qf; Sun, 23 Aug 2020 14:20:13 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 183C28091C; Sun, 23 Aug 2020 14:20:10 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 34E28806B9; Sun, 23 Aug 2020 14:20:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1598206808; bh=xHscKhkOWo08zb0go6iqFnNPXFD1fZMtiDRc6zQGbPE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=a7AABRvTEw39B6y200rKElAZmeMvIzVR9xu2dJ4/fqh51cCl9bEQWKKz48vZnIpTy 6cKvzdcz/T5V1LNA9PdsQrBv2VwZz3D16ZZrhZRmS7PGbvLM4tXUY5a2ZY2OLpCeaD ppJN9AkDxtoA5NhtMBnolByOWGFQJFk7km52HJej8iS3LZqb6PZ74VtQq7AGp4KgQV Ahd3fuOKGoWAZNXYkx5J0W938YoS3hN4Vp2ckxxnCE/TcUiM5rfmjAQVL7SI79YJV7 m/U6NJpPR3tZuIzdkG3cprWT3ckhQDbFK4tatJM/5xwN7BYvdnFs7oyyEOkvCtuiJO XLHxTxcUsFobQ== Original-Received: from alfajor (unknown [45.72.246.108]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CA48F1206B4; Sun, 23 Aug 2020 14:20:07 -0400 (EDT) In-Reply-To: (Andrea Corallo's message of "Sun, 23 Aug 2020 16:31:46 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/23 14:20:10 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254146 Archived-At: >> I don't have a clear understanding of the problem this is trying to solve. >> Could you summarize it? > > Sure, > > we need a rule to go from the source file to the eln filename. > > /xxx/foo.el -> foo-something1.eln > /yyy/foo.el -> foo-something2.eln > > Given we store all eln "flatted" in a single directory indeed we need to > have "something1" different from "something2". [...] > I then came-up with the current idea of using the source content as > input of the hash, this should be robust. Yes, the use of the content-hash should solve this problem "once and forall". Maybe the performance cost will force us to reevaluate this decision, but for now I'm happy with it, so consider it a "solved problem". > At the moment we are using 2 separate hashes to make the cleaning (easy) > possible, this is a separate problem that's correct. The idea is that > with the two hashes when recompiling is easy to just remove the old file > as you can identify using the first hash the old one. I must be missing something: in which way does the filename-hash help here? Oh, you mean we could look for -*.eln and remove them? What I was thinking of doing was: when we generate a new .elc file, just before saving the file over the old .elc file, we compute the hash of the old .elc file and erase any matching .eln file. > Additionally to that, at any point in time, if you have two file > sharing the first hash you know that all but the most recent can > be removed. Then we could move the content-hash from the .eln filename to within the .eln file itself. Note that for the "system-wide" .eln files it can be trickier because we may want to generate them once and then use them with Emacs installed at difference locations, so we'd then want to try and avoid using the absolute file name (and instead use file names that are relative to the root of the Emacs install or something). > I think this may be problematic as we could have two different Emacsen > with two different load-path that are sharing the eln-cache folders. > This may be a bit of patological case tho. No, it's definitely not pathological. It's pretty common for packages to modify the `load-path` upon first use, so your `load-path` can change long after startup. Not to mention situations where you have several different configs (e.g. I always have 2 Emacs sessions, one dedicated to Gnus and a "general" one and they share *some* of the config but not all, so they don't have the same `load-path`). Stefan