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: Finalizing 'inhibit-automatic-native-compilation' Date: Thu, 02 Feb 2023 09:55:46 +0200 Message-ID: <83v8kkxzzx.fsf@gnu.org> References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <87sffo3as7.fsf@melete.silentflame.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33235"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 02 08:56:29 2023 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 1pNUSK-0008KB-26 for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Feb 2023 08:56:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNURj-0005Ck-TW; Thu, 02 Feb 2023 02:55:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNURi-0005CX-Dh for emacs-devel@gnu.org; Thu, 02 Feb 2023 02:55:50 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNURf-0008FL-UO; Thu, 02 Feb 2023 02:55:47 -0500 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=kRGOzIkDCKalVjzs62HU4CVKDcGaxhf1lGmUm7IJ8+M=; b=Qw8Gl0htqvKl VaPMOf66aRY2JJ0BBVH3cC/T5pzzIRxJ5O/KLzTlKl8A9MsmkQ3ViCbwjS/nM7pc5gHovk+pD9MLT mR45k1p0+I/UKi/FRz7J1ZLykjwhDZ9eDaUb17yQ3z8QyD7jguQA17w3hEEJSCgRmEwTs8pWY4fdb gGdQvkYkVMVPP8chDFkBqWiFpSgP9RJw8/0O5jydOi9+TyglA0nMNbS5vPboGHhg68sxlHYnr8aSA t+f1AuIYzTY8otX1jUML9RoZAKJ1Rve60nadV3qqMEVSt4dkehirvYGTupm/Cl2LVqntqxOzQ/Wms 9rs1O2WhIzgSQXbw9+MRdA==; Original-Received: from [87.69.77.57] (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 1pNURf-00026t-7l; Thu, 02 Feb 2023 02:55:47 -0500 In-Reply-To: <87sffo3as7.fsf@melete.silentflame.com> (message from Sean Whitton on Wed, 01 Feb 2023 22:18:32 -0700) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302891 Archived-At: > From: Sean Whitton > Cc: Eli Zaretskii , emacs-devel@gnu.org, akrl@sdf.org, > larsi@gnus.org, rlb@defaultvalue.org > Date: Wed, 01 Feb 2023 22:18:32 -0700 > > On Sun 29 Jan 2023 at 09:30PM -05, Stefan Monnier wrote: > > >>> > IMO, the "no writable eln-cache" scenario should be solved by tweaking > >>> > native-comp-eln-load-path to include a writable directory. That > >>> > writable directory could be temporary-file-directory, or it could be > >>> > anything else, but it should be specified by the caller/user, not > >>> > pulled out of our hat behind the scenes. > >>> > >>> That's where I disagree: when it comes to trampolines I think users > >>> would be better served if we silently used an eln-cache in > >>> `temporary-file-directory` rather than ignoring the subr's redefinition > >>> (usually due to an advice). > >> > >> Why? in the Debian use case all they care about is that the file is > >> not written to HOME, and my proposal doesn't break that. > > > > AFAIK your proposal breaks some uses of advice. > > > >> The trampoline isn't needed in their scenario, so there's no reason to > >> generate it. > > > > I don't know if they need trampolines, but I wouldn't be surprised if > > they do on occasion. > > Some of our addon package test suites use advice in ways that mean we > need the trampolines. Thanks, but if this should be taken into consideration for the purposes of this discussion and the decision to be made as result, we need all the details you can provide about these uses. So: . what kind of advice are those and which functions they advise? . where and under what circumstances will those advised functions be called, as part of your preparation of the packages? (if the advised functions are only called when the end-user uses the package, that is not relevant to the present discussion) . what bad things will happen if the advice will not work (details, please)? . if we provide a way to specify, via comp-enable-subr-trampolines, the directory to which the trampolines will be written, will that satisfy your uses? if not, why not (details, please)? . why cannot you use native-comp-eln-load-path to force the trampolines go to a directory of your choice? . any other pertinent details you can provide TIA