From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#56743: 29.0.50; Sharing .eln files beween different builds Date: Tue, 26 Jul 2022 13:48:01 +0200 Message-ID: <87fsio3xji.fsf@gnus.org> References: <83czdufpn6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6165"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: eliz@gnu.org, monnier@iro.umontreal.ca To: 56743@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 26 13:50:09 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oGJ4i-0001Po-S5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Jul 2022 13:50:08 +0200 Original-Received: from localhost ([::1]:60100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGJ4h-0002Bq-0Z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Jul 2022 07:50:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGJ3m-00026r-8K for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 07:49:15 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34438) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGJ3e-0001WR-J6 for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 07:49:09 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oGJ3e-0008Ix-Ex for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 07:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Jul 2022 11:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56743 X-GNU-PR-Package: emacs X-Debbugs-Original-To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" X-Debbugs-Original-Cc: Eli Zaretskii , 56743@debbugs.gnu.org, Stefan Monnier Original-Received: via spool by 56743-submit@debbugs.gnu.org id=B56743.165883609931852 (code B ref 56743); Tue, 26 Jul 2022 11:49:02 +0000 Original-Received: (at 56743) by debbugs.gnu.org; 26 Jul 2022 11:48:19 +0000 Original-Received: from localhost ([127.0.0.1]:52419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGJ2w-0008He-R5 for submit@debbugs.gnu.org; Tue, 26 Jul 2022 07:48:19 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:38272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGJ2q-0008Gj-8c for 56743@debbugs.gnu.org; Tue, 26 Jul 2022 07:48:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=myNUQMS0UXJLnYyNMnhewik3fqSXOqAVGWM9c8qzPYU=; b=chYnxsselbFrdU2XV3Nm2OL6LL fgwSwfUK9NnSwiDHs0JGQW8WhKSFRgYqG/NVFw1zWJqTy97x0IZUs5F0Nu/9nG/uVFVNaUyQKFFhA akXDAl2b+nuDctggjP/dMgO8zrkZJEZKnklsxfAoxepx52g11Py3wpstgcSrHe36574c=; Original-Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGJ2f-0005mE-S3; Tue, 26 Jul 2022 13:48:04 +0200 In-Reply-To: (Stefan Monnier via's message of "Sun, 24 Jul 2022 13:49:42 -0400") Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEVTW2R6foE2P0ic pK4cIyn///9GHbZRAAAAAWJLR0QF+G/pxwAAAAlwSFlzAAAewgAAHsIBbtB1PgAAAAd0SU1FB+YH GgsrF3i7rpsAAAGgSURBVDjLhZQBkqQgDEU/cQ4A7QVSGQ7QjnuAXYr7n2l/Ajh211RNbEvN4/8E lEbK8AMKwLLBlCdQ8BbqWeZ3ICHl8sB2HPtxPktWKSkNQSrlmdN5nkcJ1xWFsR+HX+6mZqIvz3FE PFIRQDRB1WY0siReKrm3KtoklFYT4U8M6iPHScKUcPSopK3ZxPDBIrV3+nhuerVQBLCo3RYBS1DU OiWmNwm6A2uUhH0n8IOgmrcFB+HE4H0n6G5F0KMoc858ZJ2KBYLNhGi+AT8DUKLVgYb/iGXRo1+/ ad/ASR3gVRFkXK78BNU0vNp3kQXqeGwxkR8ASR/kHdhyewM6y7cJ3nqJO/PFBZbC31bzxY+ZcxHn OI13ZXMRf4wJ7DfQ6uvM+5qG3BSlZMZ6TGmLSOjINyD7vu0eJ6JbWRaP+LLZtKKP72tZYWyCmOAd dN+1Y3/4Ct6AJ+vVbrsAv5u6+vNNWVZXf2PzCU3AzhhfE/zjPTeecRelAH+WgptdppXnz49VnAAy /hYCXEtE/f7Ynuc5wPMCm0uAPQ/JBepnFEfJ/wEvdsKLrmplhQAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMi0wNy0yNlQxMTo0MzoyMyswMDowMIflMIgAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDct MjZUMTE6NDM6MjMrMDA6MDD2uIg0AAAAAElFTkSuQmCC X-Now-Playing: Neil Young's _After The Gold Rush_: "Tell Me Why" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237940 Archived-At: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > IIUC this mostly means that all the Gtk/Lucid/X11-specific > functions&variables exported to ELisp will need to be exported in all > the builds (probably with dummy definitions). I think that's an interesting idea. Currently, there's this odd difference between C- and Lisp-defined functions/variables, where Lisp-defined ones are always available, even if the Emacs build doesn't support the feature, and the C ones aren't. So it makes sense conceptually to move the DEFUN/DEFVARs outside the #ifdefs (but stub out the innards). However, I think that'll lead to a lot of regressions in code out there -- it's super common (and recommended practice) to check whether a C level function is fboundp as a signal that it works, and making these functions always available would break that. So I don't think this is a feasible direction to go in.