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: Sat, 04 Mar 2023 12:48:02 +0200 Message-ID: <83356kbxnh.fsf@gnu.org> References: <87edq7ztks.fsf.ref@yahoo.com> <87edq7ztks.fsf@yahoo.com> <83pm9reccn.fsf@gnu.org> <87v8jjxxo9.fsf@yahoo.com> <835ybje2u5.fsf@gnu.org> <87fsanxoah.fsf@yahoo.com> <83zg8vckx5.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27401"; 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 Sat Mar 04 11:48:49 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 1pYPRX-0006tH-WA for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Mar 2023 11:48:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYPR5-0001Se-3G; Sat, 04 Mar 2023 05:48:19 -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 1pYPR3-0001SL-3U for emacs-devel@gnu.org; Sat, 04 Mar 2023 05:48:17 -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 1pYPR1-0000PA-OQ; Sat, 04 Mar 2023 05:48:15 -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=xNL955kh7TbleuHGeAgzQ+RVVi4oGb066E6luG06gRI=; b=EWdO/LeVmCy7 3XdL7ot8t4o5hOoYN9BPbpRwgsnP+lvlJp4SgPNm1a6Ism/8MGJalxGdVmPbqernVrAWCTDau/yzM fUrxRlNP1wqO1TuSYbRB5S93cJvTPU4XgONA5nBZ5wzu4dSk6JbjEsKbenJmHUmzzYFdgOr1vvP7F TvbTmzKJoe/+ygb/FVSraqJCfSHrMTohdf+UFmdiQuQqkKvSrgnOntgHbnWIdxzu9scTZpR+5ft/l 4pGgxifkICSu6SoW4BrEWMr+i5nY6MzCNicdLVY/PUsIW5n8ju/1D/lLRyt6FD2VDCYm2y6sGxEzO qBvT/gLBIbq+DqeHpGloxw==; 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 1pYPR1-0002um-2j; Sat, 04 Mar 2023 05:48:15 -0500 In-Reply-To: <875ybhvt4w.fsf@yahoo.com> (message from Po Lu on Sat, 04 Mar 2023 16:05:19 +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:303942 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu > Date: Sat, 04 Mar 2023 16:05:19 +0800 > > Eli Zaretskii writes: > > > macOS builds don't use GCC. > > They use Clang, which pretends to be GCC well enough to support this > extension. > > > But if this problem is basically limited to Android, how about solving > > it in emacs-module.c, via preprocessor directives, instead? Or even > > unconditionally disable modules in the configure script for Android? > > I think making changes that affect all the platforms for the benefit > > of Android should be limited to the absolute minimum. > > This problem in emacs-module.c affects all platforms except MS-DOS. > Basically any non-GCC and non-Clang compiler cannot compile Emacs by > default. What are those "non-GCC and non-Clang compilers" that are prone to this problem? > Also, some versions of Android's GCC do support the cleanup attribute, > while others are new enough to support it but signal an ICE compiling > any code that actually uses it. And Android's clang is a hit and miss I > have not yet figured out. It is strange that GCC and Clang for Android behave differently in this regard from the same compilers configured for other platforms. The cleanup attribute is not supposed to be so platform-dependent, AFAIU. > In general, it is better to write tests for a feature than tests for a > version of one tool known to support a feature. That's why Autoconf was > created. I'm okay with writing tests for this, but can be arrange for those tests to be run only in the Android build? Once again, I'd prefer not to make non-trivial changes in our configury with a clear test case, and we don't have any such case that doesn't involve the Android build, AFAIU.