From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Native compilation: the bird-eye view Date: Sat, 16 May 2020 12:58:11 +0000 Message-ID: References: <83o8qocd32.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="87595"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 16 14:59:13 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 1jZwPJ-000Mhy-JX for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 14:59:13 +0200 Original-Received: from localhost ([::1]:54680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZwPI-0003Gj-LT for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 08:59:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZwOP-0002px-Gg for emacs-devel@gnu.org; Sat, 16 May 2020 08:58:17 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:62254) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZwOO-0005ft-0m; Sat, 16 May 2020 08:58:17 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04GCwBgn018259 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 16 May 2020 12:58:12 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04GCwBtx018855; Sat, 16 May 2020 12:58:11 GMT In-Reply-To: <83o8qocd32.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 May 2020 14:51:29 +0300") Received-SPF: pass client-ip=205.166.94.20; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/16 08:58:12 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:250486 Archived-At: Eli Zaretskii writes: > Maybe this was already discussed (in which case please point me to > that discussion), but if not: how will this feature be integrated into > the Emacs distribution and usage patterns? I don't think this was discussed already. > First, we cannot bundle the *.eln files with the source tarball of the > Emacs release, because these files are too specific to the > architecture (and perhaps also to the versions of the OS and the libc) > of the system where they were produced. Right? Correct. > If so, they will have > to be generated on the end-user machines, or perhaps by whoever > prepares the Emacs binary distributions -- assuming that the binary > distributions are sufficiently compatible to allow that, > notwithstanding the differences between the system where the *.eln > files were generated and the system where they will be installed and > used. (I don't know what is the granularity of the binary distros wrt > machine architecture and OS versions -- will that allow to be sure the > *.eln files are compatible with the target system?) Given .eln are just shareds with (almost) no dependecies [1] their degree of compatibility should be higher then the Emacs binary itself. Who is preparing the Emacs binary should be able to compile and distribute the eln files too. > The next question is whether we want the *.eln files to exist up front > for all the Lisp files on the end-user system, or we want them to be > generated in JIT-like manner, whenever the corresponding Lisp library > is loaded on demand? The answer to this question might then influence > the place where the *.eln files are kept -- the JIT alternative would > suggest to have some kind of cache directory where we put the compiled > files, similar to what Guile does. I suspect that for the average user the best is to have the distribution do all the compilation upfront for him and have deferred compilation handling only additional libraries and packages. > And finally, what about the *.elc files and their relation to the > corresponding *.eln files? Do we always load a .eln file if > available, do we let the user specify their preferences, something > else? I'd say: if the .eln is present and the suffix is not forced, this should be preferred to the .elc in the same way now we prefer the .elc to the .el. Andrea [1] This is what an .eln dynamically link against on GNU/Linux: ==== $ ldd test.eln linux-vdso.so.1 (0x00007fff6d215000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f9bb7a000) /lib64/ld-linux-x86-64.so.2 (0x00007f3f9c16f000) ==== -- akrl@sdf.org