From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.bugs Subject: bug#43476: feature/native-comp; path for .eln files when running with --no-init-file Date: Sat, 10 Oct 2020 15:12:05 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16658"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43476@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 10 21:13:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kRKIo-0004F0-Q5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Oct 2020 21:13:10 +0200 Original-Received: from localhost ([::1]:46634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRKIn-0001rm-Sn for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Oct 2020 15:13:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38510) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRKIg-0001qM-Tj for bug-gnu-emacs@gnu.org; Sat, 10 Oct 2020 15:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kRKIg-0005lF-KQ for bug-gnu-emacs@gnu.org; Sat, 10 Oct 2020 15:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kRKIg-0006Ir-Df for bug-gnu-emacs@gnu.org; Sat, 10 Oct 2020 15:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tom Gillespie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Oct 2020 19:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43476 X-GNU-PR-Package: emacs Original-Received: via spool by 43476-submit@debbugs.gnu.org id=B43476.160235714724186 (code B ref 43476); Sat, 10 Oct 2020 19:13:02 +0000 Original-Received: (at 43476) by debbugs.gnu.org; 10 Oct 2020 19:12:27 +0000 Original-Received: from localhost ([127.0.0.1]:38537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRKI7-0006I2-03 for submit@debbugs.gnu.org; Sat, 10 Oct 2020 15:12:27 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:44975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRKI2-0006Hl-2s for 43476@debbugs.gnu.org; Sat, 10 Oct 2020 15:12:25 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id t9so13936996wrq.11 for <43476@debbugs.gnu.org>; Sat, 10 Oct 2020 12:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yNBo5EdbcLRdmAS+++bpt/8oYQpGz9/TTpFHLEOeCjo=; b=rezGojFNYorYYzcwPbLixFDAKtueWOs3FbiAzUwj62394ES3LBdZVjs4Q6vdrpsRes vZ/qWLlSkRqDmnNc9h1Ef6QfqAXnzDFBd7qaymC66B8d6t0LK2neTERxFjkpE1BR+RqI N0bm8QSuFFpZ9Kh1GkswEDbVDfyigI5k/x1k+qn1eURU7gXjt7JYdE/FSBTpjQsz1IU6 A14gr3H8h2qC7haSjad9trHNYVRG4nIFQ8vv/9bnDZ3sckL4t5xGib5RGm8WR5uGHjuV 8/awi0akmlAYGAXVJYdmO7TTkhxJBbSHDrpGh7QLZ8YkNBnHJWbRWqzyo1YWsIBTo8yx +g9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yNBo5EdbcLRdmAS+++bpt/8oYQpGz9/TTpFHLEOeCjo=; b=riVbZPD156eeGiXiWlw8qDql9oARE4/kgABwS1uFaHLaDbhRDnAG0v4G6sq8uWoul2 XeRkh9/s3TFChayyDGclsYfbRJdbHsCt2B8/KBhw8PDv1chxTeuGLKq9rxu88uJXlAMK zEnTsJ0VCA2trGWxSCCHQhPG343+KRejYb9EaxUE73+DjAlmzuQ1ZncTEj/Z3xwzuMQV zYQtSy76P0muLmzHzgc2sBI/t6SO9dek+b22Ue4W5llOTAm+ctU0ncBXOIpOY+z2FHbf L23yPP+SVdojQLXqpjJdF5nK/eOFKLSjheojHDSDJYhgLbXaydPkbvjyE6+HweoE8qVR xWmQ== X-Gm-Message-State: AOAM531PoCRclOqNROJedM46UC7e/s3ffKvKYGmhmE4SlGbONpFNbhO6 xd0lXLl4Izlr7LmD6wslyWaTLC0r/GJsxPHakSs= X-Google-Smtp-Source: ABdhPJx3pQJUm4FZ9AZChHgNArqiFc6/1UljpjFEIoKEHnM1/zNza8Ihc1KWeOQUiWbGB9lLOOK1Lp71LjTlWGGsd6M= X-Received: by 2002:adf:a345:: with SMTP id d5mr22996158wrb.55.1602357136166; Sat, 10 Oct 2020 12:12:16 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:190222 Archived-At: Hi Andrea, I think it is ok to close this. I don't see an easy solution here. My workaround works, and the way that the eln files are named seems like it is safe against most common issues (I have no idea what the effect of changing versions of libgccjit would actually be, it was just a hypothetical). I think the only practical thing that could be done is to add a note to the manual about how to change the location of the eln-cache at startup. Otherwise, this bug can serve as a record in case anyone encounters an issue. Best! Tom On Sat, Oct 10, 2020 at 5:48 AM Andrea Corallo wrote: > > Tom Gillespie writes: > > > Hi Andrea, > > Not quite a bug, but an inconsistency in the behavior of > > comp-eln-load-path compared to the behavior of load-path. Best! > > Tom > > > > While investigating the json-mode kill-buffer bug I encountered an > > issue which seems like it might cause confusion at some point. > > comp-eln-load-path is set at startup and materialized. > > > > When Emacs is launched with -q, load-path does not contain the > > materialized locations of paths inside user-emacs-directory until > > after a call to package-initialize. > > > > I think that there is a similar need for comp-eln-load-path, which is > > that it needs to exclude the user eln cache path when emacs is > > launched with -q so that it is possible to debug issues arising from > > stale/bad eln files. There will be a similar issue with site-lisp and > > -Q. > > > > I don't know whether stale files could cause a problem given how you > > hash to generate the names for the eln files, but I'm imagining cases > > where someone upgraded gcc or libgccjit and something changed. I think > > that not setting the user path when Emacs is run with -q is consistent > > with Emacs behavior for load-path. > > > > Right now a user has to explicitly pop the old eln cache directory and > > then update the new directory if they reset user-emacs-directory as I > > do in the longer reproduction for the json-mode bug (reproduced > > below). > > > > #+begin_src bash > > emacs -q \ > > --eval "(setq user-emacs-directory \"/tmp/test/.emacs.d/\")" \ > > --eval "(when (boundp 'comp-eln-load-path) (pop comp-eln-load-path) > > (add-to-list 'comp-eln-load-path (concat user-emacs-directory \"eln-cache\")))" > > #+end_src > > > > I don't have a good solution for this, but wanted to raise the issue > > since I anticipate that there will be quite a bit of confusion if the > > user eln cache continues to point to the path ~/.emacs.d/eln-cache > > instead of either not being set or updating to be inside > > user-emacs-directory the first time the value is needed. > > Hi Tom, > > I think the fundamental issue is that we need a eln-cache directory to > operate anyway. So either we assume that eln compilation is correct and > transparent (current approach) or we need to set the eln-cache directory > to be in some temporary directory for every -q run. This would indeed > require the recompilation a bunch of compilation units at each -q > startup. > > I'm personally for keeping the current approach as the second one could > be annoying especially on non very powerful machines. Still a power > user (like you :) can decide not to trust the correctness assumption and > hack it around as you have showed. > > As ATM I don't have any better idea on this I'd be for closing this bug > unless some idea/action is suggested, what do you think about? > > Thanks > > Andrea