Re: Various problems and/or questions on Insight 5.2.1

[Nicholas Wourms <nwourms at netscape dot net>]

On Wed, 4 Sep 2002, Christopher Faylor wrote:

> We really can't require people to install X in order to
> get a graphical debugger for cygwin.

Please understand that all I'm trying to do is help 
facilitate a reasonable solution to a current problem.  I 
mean no disrespect or malice in my intentions.  Can we 
please keep this friendly, as I know this subject tends to 
bring out emotional debate.  Anyhow, I think co-existance 
*is* the solution, rather then forcing people to install X 
if they don't want it (or leaving it the way it is). 
However, as more and more people begin using Cygwin/XFree, 
they'll want to run their Tk apps in X.  They'll want thier 
tcl scripts to work like they do under linux  We shouldn't 
ignore their needs as well.

> I suppose but, while I can't direct people's time, it sure
> seems like focusing on fixing the native insight is a 
much > much higher priority.

I agree, having a working insight would be nice.  Still, you 
did tell people that further discussion of this should be 
done on this list.  That is what I'm doing.  My intent is 
not to de-rail the goal of a working insight.  Anyhow, after 
a brief discussion with Chuck, having two versions would be 
the best compromise.

> And, *I'm* not going to be releasing an X version of
> insight, that's for sure.

If we can come up with a reasonable solution which will 
co-exist with the w32api insight, would that make you more 
receptive?  It would be silly and dangerous for two people 
to maintain versions of insight/tcl/tk/tix/blt/itcl which 
differ in functionality.

KS>It sounds like we're agreed, there's no reason to exclude 
KS>the possibility to allow this... It's just a matter of 
KS>testing for X. If it can't find X _and_ we have a cygwin 
KS>host, then build "native". If it's unix, we bail.
KS>Doesn't sound that tough...

Why not go the original route?  To allow for coexistance of 
insight/insight-tcl,tk,tix,itcl,blt with a cygwin-native 
tcl,tk,tix,itcl,blt (which leverages X), lets look at some 
facts:

1)The insight versions of tcltk&family are really only 
useful for insight, as they screw up any attempts to 
externally leverage them (Perl-Tk, PyTK, etc.).

2)A fully posix-compliant, w32api-free, version of 
tcl/tk/tix/blt/itcl would be perfect for a default set tcltk 
tools for cygwin.  Not only would it be good for porting 
scripts, but expect would run much faster not having to make 
external calls to cygpath.  If people really want to run 
tcl/tk scripts inside the windows gui, they will use 
ActiveState tcltk.

3)Tcltk is structured such that segregating different 
versions is relatively painless.

=============================================================

What might work is to offer two packages:
* gdb.exe -> native w32api insight linked against 
w32api/cygwin based tcl/tk/tix/blt/itcl

* gdbx.exe -> native cygwin insight linked against 
cygwin/posix/Xfree based tcl/tk/tix/blt/itcl.

So why not install them like this:

w32api based insight + w32api tcl/tk/tix/blt/itcl:
--------------------------------------------------------------
1)All runtime libraries and binaries prefixed with "cyg" 
(i.e. cygtclsh, cygtcl83.dll, etc.) except gdb, which would 
still be gdb.  Install location would be /bin.
2)All import libraries would be prefixed with "cyg" (i.e. 
cygtcl83.dll.a, cygtcl83.a, etc.).
3)All insight & tcl/tk/tix/blt/itcl/redhat junk would go in 
/usr/share/insight instead of just /usr/share.
4)The insight & tcl/tk/tix/blt/itcl headers would go in 
/usr/include/insight instead of just /usr/include.
5)The tclConfig.sh and tkConfig.sh would go in /lib/insight 
instead of /lib.
6)tclConfig.sh tkConfig.sh would be built to reflect these 
settings.

native insight + posix/Xfree based tcl/tk/tix/blt/itcl:
--------------------------------------------------------------
1)All runtime libraries would be prefixed with "cygx" (i.e. 
cygxtcl83.dll) and gdb would be named gdbx.exe.  However 
tclsh, wish, etc. would retain their same names.  Install 
location would be /bin.
2)Since exe's cannot be symlinked on cygwin, all versioned 
exe's would be duplicated with non-versioned names (i.e. 
tclsh83.exe -> tclsh.exe).  This allows for detection by 
configure scripts.
3)Import libraries would retain the default naming 
conventions (libtcl83.dll.a, etc).
4)All insight & tcl/tk/tix/blt/itcl/redhat junk would go in 
the default /usr/share.
5)The insight & tcl/tk/tix/blt/itcl headers would go in the 
default /usr/include.
6)The tclConfig.sh and tkConfig.sh would go in the default /lib.

===============================================================

I know I haven't adressed Expect and DejaGnu, as I'm still 
thinking of how best to fit them into this scheme.  Of 
course, this is just my opinion on what makes sense to me. 
I'm sure others will have some things to add or remove from it.

KS>Now if we could only fix tcl/tk...

Well hopefully those links I provided earlier might have 
some relevant information, even if it is used to patch up 
the current implementation.

I look forward to contiuing discussion on this subject and 
to hopefully provide some patches (although the tcl/tk 
internals are not areas of my expertise).

Also, please CC: me as I haven't subscribed to the list.

Cheers,
Nicholas