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: [feature/dll-only-windows] A new windows build, comments wanted Date: Sat, 09 Jan 2021 22:18:06 +0200 Message-ID: <83ft39hnk1.fsf@gnu.org> References: <87pn2dq3xv.fsf@russet.org.uk> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21300"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 09 21:19:04 2021 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 1kyKhS-0005OJ-BT for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Jan 2021 21:19:02 +0100 Original-Received: from localhost ([::1]:35120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyKhR-0005ON-Dj for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Jan 2021 15:19:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyKgV-0004x8-7b for emacs-devel@gnu.org; Sat, 09 Jan 2021 15:18:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37248) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyKgU-00031t-Qz; Sat, 09 Jan 2021 15:18:02 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2092 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kyKgT-0006dh-L7; Sat, 09 Jan 2021 15:18:02 -0500 In-Reply-To: <87pn2dq3xv.fsf@russet.org.uk> (message from Phillip Lord on Sat, 09 Jan 2021 19:57:00 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:262815 Archived-At: > From: Phillip Lord > Date: Sat, 09 Jan 2021 19:57:00 +0000 > > So I have tried a new technique which is now on > feature/dll-only-windows. Essentially, I just name all of the DLLs that > Emacs uses directly and then figure out any dependencies of these using > `ntldd`. I've tried `ntldd` directly on emacs.exe which does not > work. Of course, it won't: we load all the DLLs dynamically at run time, we don't link against their import libraries. The only exceptions I know of are (1) GMP, and (2) libgccjit (in the native-comp build). > The practical upshot of this is that the dependencies file is just > a pile of DLLs. Did you verify that the DLLs include all of _their_ dependencies? If yes, how did you do that? > 2) harfbuzz is currently not working on i686. Is that a bug in the MinGW64 HarfBuzz port, or is that a bug in Emacs? I'm using a 32-bit Emacs build with HarfBuzz all the time, but it's HarfBuzz I built myself (it's available from the ezwinports site). > Before I fix this, I think it is worth asking whether I still need > to produce a i686 binary. I cannot tell you what to do, but it would be nice to have binaries that can be run on older Windows versions. So if the build supports XP and older Windows, keeping the 32-bit build would be an advantage. > 3) Currently the "no-deps" version actually includes libXpm. Emacs > starts without it, but looks ugly. I would like to no longer special > case libXpm and just make the "no-deps" download really include no > deps. I think this is reasonable, because this download is now, really > special purpose and "with-deps" is the default. If we believe no one will want the no-deps download, why have it at all? If we think someone will want it, I don't think they should be punished by having BW icons on the tool bar. > 4) Currently, native-comp is an "--with-nativecomp" option even on the > native-comp branch. It is likely to be merged this way to master? Yes, I think so. > Currently, I build the Windows distribution of Emacs with all the > default options. Which non-default options of practical importance does that leave out? > I can make an alternative release "--with-nativecomp" but needs some > effort; it also does not address the question of how I should build > Emacs for Windows when a full release of Emacs-28 happens. If, the > full release of Emacs-28 will be native-comp, I'd rather start > building snapshots with it as soon as it is merged. I think you should build --with-nativecomp. People can always uninstall libgccjit or rename it if they don't want to use native compilation. > 5) Why is it "--with-nativecomp", shouldn't it be "--with-native-comp". Probably, but we didn't yet get to splitting such thin hair in that branch ;-)