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 09:02:47 +0200 Message-ID: <83o7p9atig.fsf@gnu.org> References: <87edq7ztks.fsf.ref@yahoo.com> <87edq7ztks.fsf@yahoo.com> <83pm9reccn.fsf@gnu.org> <87v8jjxxo9.fsf@yahoo.com> <382933e4-deb5-e107-9165-d41e55949f0a@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20257"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 04 08:04:10 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 1pYLwA-00054k-JF for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Mar 2023 08:04:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYLv8-0005cf-Lu; Sat, 04 Mar 2023 02:03:06 -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 1pYLv6-0005cE-BP for emacs-devel@gnu.org; Sat, 04 Mar 2023 02:03:04 -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 1pYLv4-0001AY-PB; Sat, 04 Mar 2023 02:03:02 -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=oCc0dPjudWFHrTje2pWkfu8bQ85Mp/rD7zzOi69Xnq4=; b=BGBmh3T88kIw OjVCIu6VBAcKoKn5oL76+rhUw1cPkBe369MxNpDlcOoV0VgNixeO541uxhcvot/4fkERYgvq3ET6Y aEBYJ9J1HKFOC9cIU9K/GAOatLKfsBmmJg9CglZTmWCQQZ06fY23bujdPNszAmRXXWNfNbffw3j30 G3nj8vARWUQOzrvxYpiHqo9CMyBkEacAZJewPTEN/Nwn+zYZrbiTvnN6NBDAL6xOJkV4DMgTt/Am+ Kpri1k8nZRgy3MtQsvOk9XftPEp4c3bdh/ia7YkiTpr1RL2H6oY4Q3LxDEpAZoPpDkvnS9sKTYiMC qMsY/EHAZELxOBUonJO/xg==; 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 1pYLv3-0008VQ-4w; Sat, 04 Mar 2023 02:03:01 -0500 In-Reply-To: <382933e4-deb5-e107-9165-d41e55949f0a@cs.ucla.edu> (message from Paul Eggert on Fri, 3 Mar 2023 13:17:00 -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:303931 Archived-At: > Date: Fri, 3 Mar 2023 13:17:00 -0800 > Cc: emacs-devel@gnu.org > From: Paul Eggert > > On 2023-03-02 02:19, Po Lu wrote: > > > Paul, the Android port really needs the `printf-posix' and > > `vasprintf-posix' modules (as Android's printf ranges from ``completely > > broken'' to ``just missing %td'' depending on the OS version being > > used), but stpncpy and getline are only ``nice-to-have''s. Is there any > > downside to depending on those additional gnulib modules? And will they > > build on MS Windows as well? > > They should build. They'll bring in a lot of support modules, but if we > play our cards right those modules will be built only on Android so it's > only a matter of library code clutter. Just having lib/ files that aren't built on some platforms is not a problem, from my POV. We have that already, actually: many of those files aren't built on GNU/Linux with new enough kernel and glibc. > > 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. > > This should be doable by having two build directories, but only one copy > of the Gnulib source should be needed. The two build directories would > have different config.h files. You'd run 'configure' twice (or have two > 'configure' files if you want to be fancier). That sort of thing. I think running configure twice could be a minor annoyance, but we could arrange for the configure script or for some Makefile to run another configure script when needed. The Sourceware build tree does something like that when you build GCC, Binutils, or GDB.