From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: native-comp and resetting of search paths Date: Tue, 14 Jul 2020 08:43:55 +0000 Message-ID: References: <875zar1rn2.fsf@linaro.org> <87r1tfyz04.fsf@linaro.org> <86wo37kmaj.fsf@stephe-leake.org> <87ft9uzfnu.fsf@linaro.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23812"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Stefan Monnier , Stephen Leake , emacs-devel@gnu.org To: Alex =?utf-8?Q?Benn=C3=A9e?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 14 10:44:30 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 1jvGY9-00063E-QR for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jul 2020 10:44:29 +0200 Original-Received: from localhost ([::1]:42638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jvGY8-00055z-Qu for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jul 2020 04:44:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvGXg-0004gD-M5 for emacs-devel@gnu.org; Tue, 14 Jul 2020 04:44:00 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:53262) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvGXe-00030Q-Is for emacs-devel@gnu.org; Tue, 14 Jul 2020 04:44:00 -0400 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTP id 06E8htRW022058; Tue, 14 Jul 2020 08:43:55 GMT In-Reply-To: <87ft9uzfnu.fsf@linaro.org> ("Alex \=\?utf-8\?Q\?Benn\=C3\=A9e\=22's\?\= message of "Tue, 14 Jul 2020 09:04:05 +0100") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/14 04:24:17 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:252946 Archived-At: Alex Benn=C3=A9e writes: > Stefan Monnier writes: > >>>> Hmm odd. It's a custom variable: >>>> >>>> (defcustom elpy-rpc-pythonpath (file-name-directory (locate-library = "elpy")) >>>> "A directory to add to the PYTHONPATH for the RPC process. >>> >>> Use (locate-library "elpy.el" t); that will find the .el file, not one >>> of the compiled files. >> >> This will workaround the incompatibility introduced by the native-comp >> branch, but we should probably try and see if we can change the way the >> branch works such that such incompatibility is avoided. > > Is there a particular reason why .eln files are stored in a > sub-directory? > > I would guess there is a concern about clashing between versions of the > compiler and different architectures on network file-systems? Elns are not only arch dependent but also Emacs version + configuration dependent, so yeah this is to disambiguates these. > > The .eln files themselves are ELF files so we could just shove any extra > metadata in there although I don't know if that becomes expensive > compared to a simple file-path check? I think the issue is that we need a disambiguation at file name level to retain a reasonably fast loading system. > I assume the byte-compiler potentially has similar problems if a user > runs two different versions of Emacs but we don't dump .elc files in > special locations. Is this just not a concern that hits often enough or > something that is detected and dealt with by Emacs itself? > > I note the symbols in the eln files also have fairly unique identifiers > so maybe we are attempting to avoid a problem that's not really there? This is because lisp symbols are a superset of valid C ones, so this is another level of disambiguation but here it does not play a role. > I realise that was a lot of questions so maybe I should just propose the > eln stay in the directory of the source files and have a form like: > > /..eln I don't think we can use '/' in unix filenames IIUC your proposal. Stefan idea is about making elns completely transparent, you'll find the link my other mail. Thanks Andrea --=20 akrl@sdf.org