Re: build failure on cygwin -- LINUX5250

/usr/include/termcap.h:49: error: conflicting types for `tparm'
/usr/include/ncurses.h:717: error: previous declaration of `tparm'
make[2]: *** [buffer.lo] Error 1
make[2]: Leaving directory `/home/david/tn5250-0.17.3/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/david/tn5250-0.17.3/src'
make: *** [all-recursive] Error 1

ncurses is installed. I'm not sure what the conflict is exactly. Maybe a win32 specific bit of code that is getting confused?

With all due respect, it tells you right there on the screen what the problem is. /usr/include/termcap.h defines something called "tparm". /usr/include/ncurses.h also has something called "tparm" and it's defined differently.

This isn't a bug in tn5250 (and it's NOT win32 specific code!! Indeed, the Win32 code doesn't use either termcap or ncurses!!) it's a bug in Cygwin.

BTW, I had this error when compiling it in Cygwin long, long ago. After resolving all of the problems and getting it to compile I had a big problem: There's basically no way to make the keyboard mapping work exactly right in Cygwin.

So, I decided to create native Win32 port of TN5250 instead of building the curses version in Cygwin. Which leads me to the question... why is David trying to make the Unix version of TN5250 run in Cygwin?

On a related subject, I'm thinking we should split the code that compiles to lib5250 from the that which compiles to tn5250. Since it is only tn5250 that requires curses, there is no reason why lib5250 shouldn't be able to build without curses at all. Thoughts? How should I structure it? Make a lib subdirectory?

I'd keep lib5250 in the src subdirectory and create a curses directory and a slang directory (if we're going to maintain S/Lang, though I don't really see why we're doing that)

The point is, give each terminal type it's own subdirectory. That opens the way for other terminals to be written and included. Maybe if the GTK support is ever fixed, it could be put in a subdirectory. Or, x5250 could have it's own subdirectory (except that the license isn't compatible.)

In any case, configure.in would have to be changed to allow people to enable/disable the various terminal types that they want to build. Personally, I think that the default behavior should still be to build cursesterm -- just give the user the option to turn it off.

I just wonder if this is really worth the work. How many unix users are going to compile TN5250 without curses support? (Windows users already do compile it without curses support...) Seems like there are a lot of more important things to do... finish enhanced 5250 support, keyboard mapping, etc... rather than waste time moving code to different subdirectories and re-writing the build system...

But, it's your time, not mine.