[tin 2.0.0] snaphsots

[Urs Janßen]

I've made snapshots of the upcomming tin 2.0.0 release.
- several configure macros were updated (please test build on non
linux systems and with other compilers than gcc)
- fixed some color problems

<ftp://ftp.tin.org/pub/news/clients/tin/unstable/snapshots/>

[Dennis Preiser]

Post by Urs Janßen
I've made snapshots of the upcomming tin 2.0.0 release.
- several configure macros were updated (please test build on non
linux systems and with other compilers than gcc)

With these changes HAVE_NCURSESW_NCURSES_H remains undefined in
autoconf.h here (MacOSX).

I have an older (non-widec) ncurses under /usr and a current ncursesw
under $HOME/sw. I call configure like this:

.configure --with-screen=ncursesw --with-curses-dir=$HOME/sw ...

$HOME/sw/include/ncursesw/ncurses.h exists.

Regardless, tin is linked against ncursesw in $HOME/sw (otool -L is
similar to ldd):

% otool -L src/tin
src/tin:
/Users/dennis/sw/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/Users/dennis/sw/lib/libncursesw.5.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

Dennis

[Thomas Dickey]

Post by Dennis Preiser

Post by Urs Janßen
I've made snapshots of the upcomming tin 2.0.0 release.
- several configure macros were updated (please test build on non
linux systems and with other compilers than gcc)

With these changes HAVE_NCURSESW_NCURSES_H remains undefined in
autoconf.h here (MacOSX).

A copy of config.log and config.status would help in this case

Post by Dennis Preiser
I have an older (non-widec) ncurses under /usr and a current ncursesw
..configure --with-screen=ncursesw --with-curses-dir=$HOME/sw ...
$HOME/sw/include/ncursesw/ncurses.h exists.
Regardless, tin is linked against ncursesw in $HOME/sw (otool -L is
% otool -L src/tin
/Users/dennis/sw/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/Users/dennis/sw/lib/libncursesw.5.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)
Dennis

[Dennis Preiser]

Post by Thomas Dickey

Post by Dennis Preiser
With these changes HAVE_NCURSESW_NCURSES_H remains undefined in
autoconf.h here (MacOSX).

A copy of config.log and config.status would help in this case

Attached.

Dennis

[Thomas Dickey]

Post by Dennis Preiser

Post by Urs Janßen
I've made snapshots of the upcomming tin 2.0.0 release.
- several configure macros were updated (please test build on non
linux systems and with other compilers than gcc)

With these changes HAVE_NCURSESW_NCURSES_H remains undefined in
autoconf.h here (MacOSX).
I have an older (non-widec) ncurses under /usr and a current ncursesw
..configure --with-screen=ncursesw --with-curses-dir=$HOME/sw ...
$HOME/sw/include/ncursesw/ncurses.h exists.

yes, but the configure script is finding ncursesw/curses.h first (now).
Either would be correct.

Looks like when I added the check for ncurses*-config, then I noticed
that I needed to add a check to keep #defines such as HAVE_NCURSESW_NCURSES_H
intact. I implemented that using CF_CURSES_HEADER, which can derive more
variations than CF_NCURSES_HEADER - noting that all of the symbols in
the former are generated, while the latter provides just a few special
cases.

We can address this in different ways:

a) modify CF_CURSES_HEADER to check for ncurses.h before curses.h
That's less intrusive to tin, of course. Also, arguably the
<ncursesw/ncurses.h> makes it plainly one of the ncurses variations.

I'm attaching a patch for this.

b) just update the symbols and #include's in tin.
In a way this is preferable since "curses.h" is both the standard name
as well as being the actual file (ncurses.h is a symbolic link).

[Dennis Preiser]

Post by Thomas Dickey

Post by Dennis Preiser
With these changes HAVE_NCURSESW_NCURSES_H remains undefined in
autoconf.h here (MacOSX).
$HOME/sw/include/ncursesw/ncurses.h exists.

yes, but the configure script is finding ncursesw/curses.h first (now).
Either would be correct.
Looks like when I added the check for ncurses*-config, then I noticed
that I needed to add a check to keep #defines such as HAVE_NCURSESW_NCURSES_H
intact. I implemented that using CF_CURSES_HEADER, which can derive more
variations than CF_NCURSES_HEADER - noting that all of the symbols in
the former are generated, while the latter provides just a few special
cases.
a) modify CF_CURSES_HEADER to check for ncurses.h before curses.h
That's less intrusive to tin, of course. Also, arguably the
<ncursesw/ncurses.h> makes it plainly one of the ncurses variations.
I'm attaching a patch for this.

A version with this patch works fine. Thanks.

Dennis

[Thomas Dickey]

Post by Dennis Preiser

Post by Thomas Dickey
a) modify CF_CURSES_HEADER to check for ncurses.h before curses.h
That's less intrusive to tin, of course. Also, arguably the
<ncursesw/ncurses.h> makes it plainly one of the ncurses variations.
I'm attaching a patch for this.

A version with this patch works fine. Thanks.

no problem