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: Wed, 05 Oct 2022 17:03:17 +0300 Message-ID: <831qrmtlju.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.fsf@gnu.org> <87mtafnun5.fsf@trouble.defaultvalue.org> <83sfk6ahty.fsf@gnu.org> <8735c6b0wo.fsf@gnus.org> <87y1ty9lha.fsf@gnus.org> <87lepym6ok.fsf@trouble.defaultvalue.org> <877d1i9h7k.fsf@gnus.org> <87tu4i4dhs.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, rlb@defaultvalue.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 05 16:13:38 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 1og59U-0000UP-QH for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 16:13:37 +0200 Original-Received: from localhost ([::1]:37538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og59S-0006yw-QH for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 10:13:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4zo-0006pg-Kb for emacs-devel@gnu.org; Wed, 05 Oct 2022 10:03:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57010) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4zn-00052U-PA; Wed, 05 Oct 2022 10:03:35 -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=QT/RnvaRtW9XyNW5AQu572+JrSp76kc07upuPmMFhgQ=; b=YQzpWZ3qNLzq FEio2U50anNh27pEz8SRiyXtf/NwStql+3iqkMh2WwRyKPe4ZRn+FZLtoZPDoR7DASNLQ9PofgP7g sL41cLqL3e5qpbHsm2BKgy8i0NcKyiFyxdnahVuhCzFoG3wAVCCbQ2SUN72BsoKMnf6QqQ9hq/orZ VHD40G7P5K8QXvVykLAYFW5VhzWOPAraf48196J8AUjzTNiFC5ks5Hx0+K/wWyF19D2sSOsxG4Vdc 1HHMd2ZBFZ0IvHZdgQ4M3mvUSJTqruZIHiYXebKN4Y73FkFMuH/zgydKJqj1Q402Wg7i8sAJj8S8y CMvNq9sJfyNUX5VMJvv08g==; Original-Received: from [87.69.77.57] (port=1268 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 1og4zX-0006tJ-Ez; Wed, 05 Oct 2022 10:03:33 -0400 In-Reply-To: <87tu4i4dhs.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 05 Oct 2022 15:16:31 +0200) 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:296968 Archived-At: > From: Lars Ingebrigtsen > Cc: Rob Browning , Stefan Monnier > , Eli Zaretskii , > david@tethera.net, emacs-devel@gnu.org > Date: Wed, 05 Oct 2022 15:16:31 +0200 > > Andrea Corallo writes: > > > IIUC this would just control `load-no-native' and > > `native-comp-deferred-compilation'? I think these two are doing what > > you suggest here no? > > The latter yes -- nobody has discussed doing anything with > `load-no-native' (which is another variable that's difficult to discover > due to how it's named, and isn't documented anywhere, either). Variables that are "hard to discover" are intentionally named like that: we didn't intend them to be discoverable, because we didn't think they should be used except internally. During the last stages of native-comp development, we went through the variables in comp.c and comp.el with Andrea, and renamed those we thought would be useful so that they are easily discoverable. Please don't assume that the names you see are due to omission or negligence or ineptitude. Maybe additional ones should be renamed/aliased to be more discoverable, but before we do that, we need to understand the problems we are solving. That requires careful consideration and discussion, whereas rushing with installing changes in the area where you don't have enough prior knowledge and history ends up wreaking havoc, to say nothing of personal aggravation.