From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: Interest in windows native port, interpreters for other languages and C++ binding API. Date: Wed, 01 Feb 2017 14:39:00 +0100 Organization: Organization?!? Message-ID: <874m0eni8b.fsf@fencepost.gnu.org> References: <83lgtrw8lm.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1485956374 23088 195.159.176.226 (1 Feb 2017 13:39:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Feb 2017 13:39:34 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 01 14:39:30 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYv8E-0005jB-4U for guile-devel@m.gmane.org; Wed, 01 Feb 2017 14:39:30 +0100 Original-Received: from localhost ([::1]:51027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYv8I-0003wv-KI for guile-devel@m.gmane.org; Wed, 01 Feb 2017 08:39:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYv82-0003wf-Gf for guile-devel@gnu.org; Wed, 01 Feb 2017 08:39:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYv7z-0003b6-9P for guile-devel@gnu.org; Wed, 01 Feb 2017 08:39:18 -0500 Original-Received: from [195.159.176.226] (port=48670 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYv7z-0003ad-1s for guile-devel@gnu.org; Wed, 01 Feb 2017 08:39:15 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cYv7p-0004tz-NP for guile-devel@gnu.org; Wed, 01 Feb 2017 14:39:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 75 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw Cancel-Lock: sha1:ro/PVaKD3QqNXwlcVPz3/en2kLU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18880 Archived-At: Germán Diago writes: > 2017-01-31 22:29 GMT+07:00 Eli Zaretskii : > >> >> >> Not my place to answer that, but let me just say that I didn't have >> any problems using the present autotools-based build system on >> Windows with MSYS. The absolute majority of the problems I needed to >> solve while working on the port had nothing to do with autotools, but >> with various non-portable and Posix-centric stuff in the Guile sources >> (most of them were fixed since then using the patches I proposed). >> > > Well, provided that you are tied to msys and you can never ever compile > guile with a microsoft compiler, that is ok. You are talking only about > your use case. The reality is quite different: if you want windows > adoption, you need to use the native toolchain to compile. I have extensive > experience with cmake and autotools and quite a bit with meson already. I > can say with confidence that keeping autotools and taking windows seriously > at the same time is just impossible. The GNU project does not actually take "Windows seriously" to the degree that it demands using a non-free compiler chain. I can only agree about half with your assessment: I can say with confidence that taking Windows seriously at the same time as GNU/Linux and other unixy platforms is only possible with a permanent serious drain of resources. GNU LilyPond does not take Windows seriously. It does not even try to make it compile with proprietary compilers. Instead it uses a huge crosscompiling setup to release binary packages simultaneously for Windows, MacOSX (also on PowerPC), several GNU/Linux and FreeBSD variants, about every 2 weeks. Development can only be done sensibly on GNU/Linux, we provide a virtual Ubuntu environment with the necessary packages installed. A large percentage of Lilypond's user base and about 80% of its "supporting staff" (servers, regression tests, bug handling etc) use Windows. Developer mindshare invested into Windows is zero, unless the porting machine breaks. Which happens every few years on average, requiring updates for the crosscompiled libraries or crosscompiling compilers. Both what Eli calls serious Windows support of Emacs (and if you take a look at his commits in that area, it does not really deserve any other name) as well as what, say, projects like Git invest as a permanent drain of developer energy and fun into supporting Windows are way more effort than LilyPond spends here. > So my view here is that to have a decent windows port we would need > native windows threads and compile with microsoft compiler (that is > why I would be proposing meson). You just have to see the gstreamer > guys experience when switching to meson and the huge improvement it > was, especially in windows. If you don't want a permanent fixture of developers to non-free platforms, that is not my experience. For an inherently GUI-bound program like Emacs, of course crosscompilation would not answer _all_ questions. You still need all the relevant surface-dependent code, of course. And debugging _that_ when the only sensible user-accessible way is to wait for the fortnightly monster crosscompilation run is not an option. But you really cannot maintain one large project sensibly under two fundamentally different toolchains. Particularly not a GNU-relevant one that will want to be able to access a number of UNIX-typical facilities and programs in order not to degress into what programming was before the seventies. -- David Kastrup