Re: Interest in windows native port, interpreters for other languages and C++ binding API.

[David Kastrup]

Germán Diago <address@hidden> writes:

> 2017-01-31 22:29 GMT+07:00 Eli Zaretskii <address@hidden>:
>
>>
>>
>> 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