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: Thu, 02 Mar 2023 14:48:34 +0200 Message-ID: <835ybje2u5.fsf@gnu.org> References: <87edq7ztks.fsf.ref@yahoo.com> <87edq7ztks.fsf@yahoo.com> <83pm9reccn.fsf@gnu.org> <87v8jjxxo9.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10535"; 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 Thu Mar 02 13:55: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 1pXiT3-0002ZK-2B for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Mar 2023 13:55:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pXiMV-0006Jg-JD; Thu, 02 Mar 2023 07:48:43 -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 1pXiMT-0006AP-2B for emacs-devel@gnu.org; Thu, 02 Mar 2023 07:48:41 -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 1pXiMR-00086M-M4; Thu, 02 Mar 2023 07:48:39 -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=0G2+A8NpKQk6LWvF7KA7DS93hdTQ/pPXYUAF0oovRT4=; b=UzXMd3EFFXTe sjXVvGqXQW5MMI24wqtJ+k/DW0jtIsRyTCBLl2AgpqD/JXepMnfg9YI9eNnmVPaZxKxXK1lWqei+v iIgeXptIsy6PPdAJKIV/vNxxWvg3JPbWmv0XWmoh3uI+Ei4deUoBVEl79++yW0sE//R7JHEDiM7Hg I6iJYtUbrhgFg8fwux0HhmELZ91HNZlXD/bKNKWjewP0dhGY0t2cWZeHE+xRK+0jWteCXbOQ78HDG 493zBLAH28ROBDOWPX23T7jdTsCXKjh2+u4SEaaD3Z1CYkD9BM1VmdxzMJxOIHvLBzlTQv31m+caP iRNNPiIBTsleilx2Fbd51Q==; 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 1pXiMQ-00033r-T8; Thu, 02 Mar 2023 07:48:39 -0500 In-Reply-To: <87v8jjxxo9.fsf@yahoo.com> (message from Po Lu on Thu, 02 Mar 2023 18:19:50 +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:303893 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org, Paul Eggert > Date: Thu, 02 Mar 2023 18:19:50 +0800 > > Eli Zaretskii writes: > > > . The PATCH FOR LIBXML2 part and similar parts for patching other > > libraries and components should also be in separate files, suitable > > for submitting to Patch or similar utilities, and INSTALL should > > only mention the need for these patch and refer to those files. > > What would be a good place to put these patch files? admin/notes > perhaps? In the same android/ subdirectory, I think. > > -OPTION_DEFAULT_ON([modules],[don't compile with dynamic modules support]) > > +OPTION_DEFAULT_IFAVAILABLE([modules],[don't compile with dynamic modules support]) > > > > Why was this changed to "ifavailable"? > > Because the modules code has a dependency on the GCC cleanup function > extension, and fails to compile when it is not present. I rewrote the > configury to detect the presence of the extension and not build with > modules when that is in effect. Rewriting the configury is OK, but that still doesn't need ifavailable, AFAIU. For example, we build with HarfBuzz if that is available, but we don't use ifavailable for it. How is this one different? > > The files in cross/lib/ seem to be from Gnulib? If so, do we really > > need another copy of them in the tree? any way to reuse the sources in > > lib/ instead? > > I tried multiple times, but the gnulib stuff kept trying to include > generated headers from the wrong copy of gnulib, so in the end I > couldn't find any way around having to keep two copies of gnulib > in-tree. What do you mean by "from the wrong copy"? The two copies are identical, no? They are generated for the same platform, right? In any case, before we include two copies, we should ask Gnulib folks for help in this matter.