Re: Building termlib on Windows (with terminal drivers)

[Anonymous Maarten]

Hello Jurgen!

 

Otoh I‘m very interested in your work using MSVC to compile. Maybe we can collaborate on the Windows build and make sure, that Win10 will have a fully functional termlib foundation for ncurses as the preferred implementation instead of the previous limited term-driver implementation, which was targeted on older Windows versions.

My MSVC patches were focused on getting ncurses to build on MSVC with the least amount of changes required.

I've done this with the goal of creating a conan package. It would have been a waste of time if I would have not upstreamed these.

 

I‘ve a fork of Thomas‘ repo on https://github.com/juergenpf/ncurses-snapshots and I‘m developing there on branches named dev_winconsoleYYYYMMDD, where the date mirrors the snapshot dates and the branch is kept in sync with the snapshots.

If you would like to collaborate, I can add you either as contributor to that repo or accept and merge your. PR‘s, whatever you like. Thomas can then pull periodically from these branches and merge with his master branch.

I'm no windows specialist, but I'm willing to help.

Can you enable issues on your fork so you/we can collaborate on the work that needs to be done?

I don't know what todo's you have in mind for windows 10 support.

You will have to create some issues to get things started.

 

BTW, in parallel I‘m preparing a repo with a very complete .NET Core binding to all the ncurses libs, it is already compiling and working on all major .NET Core supported platforms (Windows 64Bit, Linux x64, armhf and arm64, MacOS Intel 64Bit). But that needs some more refactoring, testing and tuning before I feel comfortable to publish it. In order to create these bindings, I‘ve created a XML based metadata description of the ncurses ABI and implemented a codegenerator for C#. Long term vision is to use that approach to generate bindings for other languages by implementing appropriate code generators for these languages.

Does it make sense to use swig for this? It is able to generate bindings for quite some languages.

See http://swig.org/

 

Regards

Jürgen

Am 03.10.2020 um 21:45 schrieb Thomas Dickey <dickey@his.com>:

On Sat, Oct 03, 2020 at 08:07:30PM +0200, Anonymous Maarten wrote:

Hello!

Building the terminfo library on Windows is currently not possible

(--enable-termlib).

The configure script fails because Windows requires a terminal driver,

which is incompatible with termlib.

See

https://github.com/ThomasDickey/ncurses-snapshots/blob/2d4d88d2ed06c478e6149556f453f09d23dc1c7d/configure.in#L1176-L1184

When building notcurses, tinfo is required.

See

https://github.com/dankamongmen/notcurses/blob/a29bfe9c4238c516a227d5f5c92b60b6a56f69b8/CMakeLists.txt#L76

Is there a possibility to move the terminal driver to the tinfo library?

perhaps - Juergen moved some stuff which may be relevant to the check
that I added in 2015.

With the check removed in the configure script, the regular
MinGW build currently fails due to the wide-character fallbacks and the
stubs for terminal I/O (such as isatty) being missing from the tinfo build.

If those were moved to the low-level library, it might be possible to link
with the resulting pair of libraries.  (The pieces that I see failing don't
have dependencies on the high-level library).

What are the technical obstacles?

if it's as simple as I see at the moment, it's "only" moving things around
and verifying against the build configurations.

--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

<smime.p7m>

On Mon, 5 Oct 2020 at 21:05, Jürgen Pfeifer <juergen@familiepfeifer.de> wrote:

Hi Maarten,

I am planning to look into that and to refactor the Windows support so one can build a separate termlib, but that‘s not top priority on my ToDo list, and I’ve been lazy the last 4 weeks, but will speed up again in the next days. 

Otoh I‘m very interested in your work using MSVC to compile. Maybe we can collaborate on the Windows build and make sure, that Win10 will have a fully functional termlib foundation for ncurses as the preferred implementation instead of the previous limited term-driver implementation, which was targeted on older Windows versions.

I‘ve a fork of Thomas‘ repo on https://github.com/juergenpf/ncurses-snapshots and I‘m developing there on branches named dev_winconsoleYYYYMMDD, where the date mirrors the snapshot dates and the branch is kept in sync with the snapshots.

If you would like to collaborate, I can add you either as contributor to that repo or accept and merge your. PR‘s, whatever you like. Thomas can then pull periodically from these branches and merge with his master branch.

BTW, in parallel I‘m preparing a repo with a very complete .NET Core binding to all the ncurses libs, it is already compiling and working on all major .NET Core supported platforms (Windows 64Bit, Linux x64, armhf and arm64, MacOS Intel 64Bit). But that needs some more refactoring, testing and tuning before I feel comfortable to publish it. In order to create these bindings, I‘ve created a XML based metadata description of the ncurses ABI and implemented a codegenerator for C#. Long term vision is to use that approach to generate bindings for other languages by implementing appropriate code generators for these languages.

Regards

Jürgen

Am 03.10.2020 um 21:45 schrieb Thomas Dickey <dickey@his.com>:

On Sat, Oct 03, 2020 at 08:07:30PM +0200, Anonymous Maarten wrote:

Hello!

Building the terminfo library on Windows is currently not possible

(--enable-termlib).

The configure script fails because Windows requires a terminal driver,

which is incompatible with termlib.

See

https://github.com/ThomasDickey/ncurses-snapshots/blob/2d4d88d2ed06c478e6149556f453f09d23dc1c7d/configure.in#L1176-L1184

When building notcurses, tinfo is required.

See

https://github.com/dankamongmen/notcurses/blob/a29bfe9c4238c516a227d5f5c92b60b6a56f69b8/CMakeLists.txt#L76

Is there a possibility to move the terminal driver to the tinfo library?

perhaps - Juergen moved some stuff which may be relevant to the check
that I added in 2015.

With the check removed in the configure script, the regular
MinGW build currently fails due to the wide-character fallbacks and the
stubs for terminal I/O (such as isatty) being missing from the tinfo build.

If those were moved to the low-level library, it might be possible to link
with the resulting pair of libraries.  (The pieces that I see failing don't
have dependencies on the high-level library).

What are the technical obstacles?

if it's as simple as I see at the moment, it's "only" moving things around
and verifying against the build configurations.

--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

<smime.p7m>