From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Liliana Marie Prikler Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Wed, 12 Oct 2022 22:22:46 +0200 Message-ID: <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> References: <87ill8paw7.fsf@trouble.defaultvalue.org> <83o7uzivey.fsf@gnu.org> 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="7934"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.46.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 13 07:04:05 2022 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 1oiqO5-0001q0-2X for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 07:04:05 +0200 Original-Received: from localhost ([::1]:37050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiqO3-0007Hr-Sm for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 01:04:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiiFk-0005Dr-1v for emacs-devel@gnu.org; Wed, 12 Oct 2022 16:22:58 -0400 Original-Received: from mail-ej1-x644.google.com ([2a00:1450:4864:20::644]:41877) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oiiFi-0002n5-6X; Wed, 12 Oct 2022 16:22:55 -0400 Original-Received: by mail-ej1-x644.google.com with SMTP id d26so1320540ejc.8; Wed, 12 Oct 2022 13:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=Uf/AYQQOUPLFmHAlVy1bps4IRVmNebV5ki7ToissQGM=; b=G9aG814tr4GJZ1IZPSFDPn3ufwDxOME9iozeMBdC41IMviF0qTrtESPgfpu0+79LNA mErb12TQ3/wOXJ8QDm8tWenoCrJNq0a0KZj0TiCMnjdqFWtHRwbMmv0oRRYyblZHeWrZ SZZ+vARdxHvZGVIW9NhWgzVjJdQ/cTKTF7DY7MroDGv1OFpK3r6ivG8jWU7SRZ+9G/yr 4HKWdYk+Ozdu1Rzs9iLBHnfwBCEB/xtWpVrJKMiVV0Ii9aqoOVfFpn6ziDEIVzUe7LFV zHo7CflCrHyyex4z/uhq5PacKeHlzx/NiOc4xv3S2+OuNd/Wa3wAfoTuIIxnmF001jZj uquA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Uf/AYQQOUPLFmHAlVy1bps4IRVmNebV5ki7ToissQGM=; b=UTD68x5wWx+TN0Kg5zKubtWq2FkMyopLteyuytqP8f+lor3HoiZxxvc7YmjqEUUGy2 MOeTiGrxx17f84OCiVew34GvpIVYamoWgjPj5Ygias0RGiG3iKjYYrK6rcrT81eJGOfs rhYuLJGwBjvjf9wX87MxSUjA7qOIIqORMjMk28sOEDlVd5zp0Yjw2Y0GtgQNZkgqpWby ku6NHNYLpFTDex9g0BOBWkdyObw58wvkt00syNeDzZHBVEIs3tIigC/G8Br1idV9ZClx BMZddnPug3OqNhbHzIfkDRpOHHD508UayN66plgQFI+bB2Vdlcmsz2LsUTzOhoOmLMjT Ol2g== X-Gm-Message-State: ACrzQf0K8RyegxgB/3p9aGO6BQvVbgHvb6PxBngjnhz88Nl+IL2GyVYv 3wr1Hpp/rvAw3x8DejgreB5ixI/bkR4= X-Google-Smtp-Source: AMsMyM4Beywnz7qnvzDdlUeEaRYcsmth/cvYX2B8Wm71349JC7+64vALfeMkb4bQCAQiGdYaDpjzDQ== X-Received: by 2002:a17:907:2bec:b0:78d:8bd0:61ee with SMTP id gv44-20020a1709072bec00b0078d8bd061eemr20862019ejc.669.1665606169419; Wed, 12 Oct 2022 13:22:49 -0700 (PDT) Original-Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id v29-20020a50d09d000000b004580296bb0bsm11905473edd.83.2022.10.12.13.22.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 13:22:48 -0700 (PDT) In-Reply-To: <83o7uzivey.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::644; envelope-from=liliana.prikler@gmail.com; helo=mail-ej1-x644.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 13 Oct 2022 01:01:29 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:297652 Archived-At: Hi Eli, Am Mittwoch, dem 28.09.2022 um 14:35 +0300 schrieb Eli Zaretskii: >=20 > What do you mean by "disable native compilation" here, and what > exactly are the use cases for this?=C2=A0 Are we talking about users who > installed Emacs with some *.eln files, and from time to time load > *.elc files that have no corresponding *.eln files?=C2=A0 Or are we > talking about something else?=C2=A0 If the former, why do these users > install Emacs with native-compilation to begin with? >=20 > More generally, we never expected people who have Emacs with native > compilation available to want to disable it.=C2=A0 It made no sense to us > during development of Emacs 28, and frankly, it still doesn't, at > least to me.=C2=A0 It is so easy to install Emacs without these > capabilities and never look back that we thought providing a > build-time option should be enough.=C2=A0 (Well, except for MS-Windows > users, where more is needed, but that's not your worry.) >=20 > Therefore, if we need to discuss introduction of run-time features > for disabling native-compilation, we need to have a broader view of > the relevant use cases and user needs.=C2=A0 This includes at least the > following aspects that need to be discussed and clarified: >=20 > =C2=A0 . What does "disable native-compilation" mean, exactly?=C2=A0 Ther= e are > =C2=A0=C2=A0=C2=A0 several possible interpretations of that.=C2=A0 Do peo= ple want to > =C2=A0=C2=A0=C2=A0 prevent Emacs from looking for and loading the *.eln f= iles, and > =C2=A0=C2=A0=C2=A0 use the *.elc files instead?=C2=A0 Or do people only w= ant to prevent > =C2=A0=C2=A0=C2=A0 Emacs from compiling new *.eln files?=C2=A0 Or do peop= le want that > =C2=A0=C2=A0=C2=A0 *.eln files be produced only by an explicit user comma= nd, not > =C2=A0=C2=A0=C2=A0 transparently and asynchronously?=C2=A0 Or something e= lse? >=20 > =C2=A0 . When and why would people want any of the above to be possible? >=20 > =C2=A0 . How and why would downstream distros want to support such > =C2=A0=C2=A0=C2=A0 capabilities? In GNU Guix, we observe certain packages breaking when trying to compile them natively. While some of that is on us for messing up the package descriptions, one could also encounter genuine bugs in native compilation that one wants to work around by disabling it. (For added trouble, whether or not your package breaks could depend on the CPU due to being *native* compilation; thus the "no-native-compile" local variable is insufficient to address this generally.) In GNU Guix, we default to not compiling packages ahead-of-time, instead using a minimal emacs that can only do byte compilation for most packages. Users can however pretty easily switch to ahead-of-time compilation by swapping out the emacs package (using what Guix calls package transformations). This is also important because apart from the current Emacs we typically provide an emacs-next package for upcoming versions, as well as some other variants that the user might want to use instead. Again, we assume that users who want to opt in to native compilation do so via a transformation. In this context, the default of compiling everything that has hitherto only been byte-compiled is an ill-advised choice. Now, there is a chance that the user meant to do this anyway, but I think they rather a) use whatever the distro default is without caring either way or b) actually didn't want this package natively compiled. Due to some packages breaking, we had a lot of b) in our mailing lists in the past few days. As for loading, I think there could be a case made to restrict loading to certain directories managed by "trusted entities", but I think native-comp-eln-load-path already accomplishes this. If one wanted to disable loading altogether, I'm pretty sure one could set it to nil and be done (with perhaps the exception that deferred compilation breaks if there's no path to store binaries in). Thus, I think the issue is really only one of inadvertently launching deferred compilation when all the packages the user *expects* to be natively compiled are already ensured to be compiled ahead-of-time. I admit that this is taking a rather conservative stance, in which the users don't want to have anything natively compiled that they don't know of (and as a side result are happy to run that as bytecode or interpreted code). I hope this answers some of the questions raised. In short, we believe that users might want to control not only from where native shared libraries will be loaded, but also whether to generate them at runtime, and that (distro) package managers should enable them to compile all such shared libraries ahead of time =E2=80=93 and better yet, in a reproduc= ible manner, but this hits other bugs I do not want to discuss in detail at the moment. Cheers=20