Re: [bug-ncurses] ncurses 6.0 and cur_term function

[Thomas Dickey]

On Mon, Sep 21, 2015 at 12:12:04PM +0200, Dr. Werner Fink wrote:
> On Mon, Sep 21, 2015 at 05:09:40AM -0400, Thomas Dickey wrote:
> > On Mon, Sep 21, 2015 at 10:47:54AM +0200, Dr. Werner Fink wrote:
> > > 
> > > Does this mean I should switch over to use several tinfo libraries, one
> > > for threaded and one for wide+threaded?
> > 
> > As I said, there are pros/cons:
> > 
> > pro:
> > a) making one tinfo library is doable, and (mostly) reduces the number of
> >    libraries.
> > b) functions are bound to the same external symbols.  Global variables are
> >    not -- they are renamed and wrapped in a macro so that I could enforce
> >    readonly access to help with mutexes.
> > c) most applications calling the terminfo level use only the functions.
> > 
> > con:
> > a) the renaming of global variables isn't (can't be) binary-compatible with
> >    applications compiled on another platform.
> > b) applications which attempt to declare those variables for themselves are
> >    broken either way, but break noticeably when linked with the renamed
> >    variables.
> > c) there are a few useful configuration choices (wide/normal, 
> > thread/nonthread)
> >    with variations.  I made it possible (by overriding the choice of 
> > map-file)
> >    to switch between the choices (or even generating a new set of map-files 
> > --
> >    I'm slow -- too many things in progress -- but do intend documenting the
> >    scripts...).
> > 
> > > On OpenSUSE the libncurses6 is threaded as well as libncursesw6.  IMHO
> > > it makes no sence to use a third library which is none threaded as this
> > > will make users more disoriented.
> > > 
> > > And what does `bent the rules' mean here? AFAICS and AFAIK the libtinfo
> > > for both libncurses6 (which is threaded) as wel las libncursesw6 are
> > > binary comptible.
> > 
> > more/less along the lines of surprising the developer by putting libncursest
> > in a file that says libncurses
> 
> Just my two cents worth I had the thought that starting with ABI 6 it would
> make a lot of sense to provide noadays the ABI 6 in a threaded version only.
> This because a lot of modern programs are required to use thread safe 
> libraries.

Some are, but almost all of the ones that I notice (and reply to) have
trouble using threads in C.  I don't recall more than 1-2 who have built
ncursest/ncursestw (since few packages provide it) and written something
useful.

The purpose of ABI 6 was the colors/mouse extensions.  The thread-support
is (like normal/wide characters) mostly independent of the ABI 5/6.  But
unlike normal/wide, while it's arguably API-compatible, it's not
ABI-compatible.
 
> I had tried also a lot of version and one was the matrix
> 
>        without t and without w
>        with t and without w
>        without t and with w
>        with t and with t
> 
> for ABI 6 and similar for ABI 5 causing a lot of libraries together with
> a lot of runtime configurations and a huge number of bug reports which
> indeed had been done because users had lost overview (which user does
> read manuals and/or guides) and/or had mixed the several versions out of
> the matrix and sometime between the two ABI versions.

users don't read FAQs either (not much I can do about that...)

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature