This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: Various problems and/or questions on Insight 5.2.1
- From: Nicholas Wourms <nwourms at netscape dot net>
- To: insight at sources dot redhat dot com
- Date: Thu, 05 Sep 2002 11:24:48 -0400
- Subject: Re: Various problems and/or questions on Insight 5.2.1
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