From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Thu, 06 Oct 2022 08:28:04 +0300 Message-ID: <838rltseqj.fsf@gnu.org> References: <83sfk6ahty.fsf@gnu.org> <87v8p1aiof.fsf@melete.silentflame.com> <87v8p01lbu.fsf@yahoo.com> <83lepwvzxq.fsf@gnu.org> <871qroyog9.fsf@yahoo.com> <837d1gvt35.fsf@gnu.org> <87sfk3yl10.fsf@yahoo.com> <87o7uqtlsl.fsf@yahoo.com> <878rlu48kq.fsf@gnus.org> <83r0zmrzcx.fsf@gnu.org> <83lepuruoo.fsf@gnu.org> <92d8fa67a9a90c046b0c@heytings.org> <83czb6rrg9.fsf@gnu.org> <92d8fa67a976fb6c85a5@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27209"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 06 07:29:15 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 1ogJRb-0006qW-AW for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Oct 2022 07:29:15 +0200 Original-Received: from localhost ([::1]:50196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogJRa-0004h8-Bm for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Oct 2022 01:29:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogJQU-0003yV-Qp for emacs-devel@gnu.org; Thu, 06 Oct 2022 01:28:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogJQT-00043f-Tj; Thu, 06 Oct 2022 01:28:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=71kTkvwLi9LvYrflvvjtgrj/1FMfeKwuFoGfHPaLr0A=; b=R7S+iPWgch6d nHQxaxPUh35HX3l3ijVAYPmaA7N9+Jhltoh1ssJhxs8D0H4UYITEW3WjTPg/wzVpRNz8bgr008w93 urqhfQNgbGGP+gp/kNu8ZD4ILUGlULCmt7ha8Ug8d8ug4VXpaX83kxoV8c6ghkCZkq/YpVhRc2+tB op7jes1vscn7UU2l5N/iS6uCoElRby5HWSnDi6BVVrb0jXPgApeltjiTU9tnPxEeUZEgC1UHI9/iS psn99O++41a0vu1jpK53wFdEtN6VDEgonoUcoV7Vmw0TSCSoEDCKloekXkO5nmZuJebdzfTk24oHe GJgNn5phm7pF/AcN2X2M1g==; Original-Received: from [87.69.77.57] (port=2491 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogJQT-0003vi-CO; Thu, 06 Oct 2022 01:28:05 -0400 In-Reply-To: <92d8fa67a976fb6c85a5@heytings.org> (message from Gregory Heytings on Wed, 05 Oct 2022 20:04:34 +0000) 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:297055 Archived-At: > Date: Wed, 05 Oct 2022 20:04:34 +0000 > From: Gregory Heytings > cc: tomas@tuxteam.de, emacs-devel@gnu.org > > IIUC, what Rob wants is that > > (1) on Debian systems on which Emacs packages are built, the build process > is running as root, and nothing should be written in /root, and For this case, Rob said the workspace is thrown away after the build, so whether the *.eln files are or aren't produced is not relevant. But if, for some reason, the *.eln files could survive the deletion of the workspace, then tweaking native-comp-eln-load-path to have /tmp at the beginning should handle that as well. > (2) on user systems on which elpa-* packages are installed, the > installation process, during which el files are compiled to elc and eln > files, is running as root, and it should not write anything in /root. Since the elpa-* package installation process is supposed to leave the users of the system with ready *.eln files from the packages being installed, the installation process should NOT disable native-compilation. Instead, it should tweak native-comp-eln-load-path so that it includes the shared directory where Debian wants to have the *.eln files of ELPA packages instead or ahead of the user's eln-cache directory. This will produce the *.eln files in the place where Debian wants them, and allow users to use those packages without worrying about compilation. IOW, an option to disable native-compilation is not TRT in this case.