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: Merging feature/android Date: Sun, 05 Mar 2023 13:44:42 +0200 Message-ID: <83mt4r8lsl.fsf@gnu.org> References: <87edq7ztks.fsf.ref@yahoo.com> <87bklay7wg.fsf@yahoo.com> <83ilficn4k.fsf@gnu.org> <87zg8uw9b9.fsf@yahoo.com> <837cvycjse.fsf@gnu.org> <87ttz2w4c3.fsf@yahoo.com> <83356mcbxw.fsf@gnu.org> <87pm9qvu9w.fsf@yahoo.com> <83y1odc37g.fsf@gnu.org> <87cz5pwf9c.fsf@yahoo.com> <83edq5asb3.fsf@gnu.org> <875ybhvt4w.fsf@yahoo.com> <83356kbxnh.fsf@gnu.org> <87lekcvho4.fsf@yahoo.com> <83r0u4adgd.fsf@gnu.org> <87a60suknn.fsf@yahoo.com> <83356jafll.fsf@gnu.org> <87o7p7tz16.fsf@yahoo.com> <83sfej8v17.fsf@gnu.org> <87fsajtrrx.fsf@yahoo.com> <83o7p78ns8.fsf@gnu.org> <87y1obsamf.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17964"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 05 12:45:31 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 1pYmnz-0004U5-N0 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Mar 2023 12:45:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYmnO-00009i-Hb; Sun, 05 Mar 2023 06:44:54 -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 1pYmnM-00009F-V7 for emacs-devel@gnu.org; Sun, 05 Mar 2023 06:44:52 -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 1pYmnM-0001Iv-MH; Sun, 05 Mar 2023 06:44:52 -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=KI7LdWZw5XtIcKdvRz82N7UKM2jPXiH58PTIWs23jGM=; b=pORu15hPBO/3 A9ktaLmyJkvhQCkfQ5mNjWNDv0kJyEInksDI6PQYNQdddcEMF3eQ0SzhzTnaUiLLkopwDAIKsuAur R/VEnkGdd+b/Yw14N96+luLE0CSrbxAaqI8oS3W0vq9v2aFA6N+uOMFXRNVLF79mN5SWQhYlZfEcc r2lSDpdOt0eXCvyGjGKkitRAB44AfsGYWNBltOs0+DJZqyfkMGL+cO4edaoN0yuraFynOWo2A3FXg yfXrs94SauyTPcYKN/sW1qHDPT5qXSbDKnL5a/hs334Ai2l0Jz31y2smWBQ1GDU9phpKeNEOn2pa4 O8JYHeI+cPe3hnUSHYGhWQ==; 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 1pYmnL-0002SU-Tn; Sun, 05 Mar 2023 06:44:52 -0500 In-Reply-To: <87y1obsamf.fsf@yahoo.com> (message from Po Lu on Sun, 05 Mar 2023 19:25:44 +0800) 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:303978 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu > Date: Sun, 05 Mar 2023 19:25:44 +0800 > > Eli Zaretskii writes: > > > We made modules supported by default 2 releases ago, and I don't want > > to risk silently dropping that in configurations that up till now > > didn't need the test at all. > > What about printing a warning after configuration, if configure > concluded that the compiler does not support the attribute? Then it > wouldn't be so silent. Warnings during the run of configure go unnoticed, since configure is extremely chatty and shows a lot of routine messages. I originally suggested to fail with an error, like we do for image libraries, and you objected. I still think that is the best alternative. It will make sure users are aware of the issue, and can decide whether to look and solve the problem or use ifavailable instead. > BTW, I'd like to see the discussion where it was concluded that the > cleanup attribute is absolutely required. It doesn't do fancy things > like clean up after Lisp signals under the hood, so all of the cleanup > can be done in portable C as well. AFAICT, this attribute was used from the very beginning.