tcl/tk/expect/dejagnu/gdb/insight [Was: Re: [PATCH] Define _TIMEVAL_DEFINED consistently whenever defining timeval.]
Charles Wilson
cygwin@cwilson.fastmail.fm
Wed Sep 16 17:57:00 GMT 2009
Christopher Faylor wrote:
> On Mon, Sep 14, 2009 at 07:01:44PM -0400, Charles Wilson wrote:
>>From this thread:
>> http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html
>> I thought most people either were in favor of, or at least not opposed
>> to, "fixing" the */tk/*/insight issue by switching to an X-based tk. It
>> was just waiting on enough cgf-tuits (and, perhaps, the long-delayed gdb
>> 7.0 release and/or Insight 7.0).
>
> I did get tcl and (I think) tk building but then found that insight
> needed other libraries too.
Yep: Itcl, Itk, and Iwidgets.
I've got those, too, each built from the new "separate", TEA-compliant
source tarballs.
A quick-n-dirty build of insight (current CVS) seems to work with minor
patching. However...
there seems to be a lot of "entanglement" in the insight codebase. The
idea that "cygwin == win32 tcl" is an assumption that runs throughout
the code. For instance, a lot of stuff is guarded by '#ifdef _WIN32'
rather than one of
'#if defined(_WIN32) && !defined(__CYGWIN__)'
'#if defined(_WIN32) || defined(__CYGWIN__)'
or, the best alternative, something like
'#if defined(_WIN32_TCL)'
Also, the configury, by default, arranges for -D_WIN32 -mwin32. And,
even when you "fix" the configury to not do that, any time <windows.h>
is included it comes back, zombie-like.
And last, you have to use --disable-werror on cyg1.7 because insight
uses the old path conversion functions (cygwin_conv_to_full_win32_path
and friends), which causes deprecation warnings.
So, while my version seems to "work" in my brief testing -- it is
definitely a rough approximation to a true, cygwin/X version of insight.
I'm not sure anybody wants to put the effort into the dying insight
codebase to "do it right".
Now, whether insight is dropped or not, I still think it would be good
to have "real" X-based tcl/tk in the distro, even though that would
cause knock-on effects to expect, git, python [*], and ruby. The big
drawback last year was that at the time, we were still in limbo with
regards to a working cygwin xserver (we had the modularized libs, but
the xorg-7.x server was still WIP). That's no longer the case.
[*] for instance, the 'idle' GUI becomes X-based, as does gitk (and they
probably need recompilation or they'll simply break) -- (actually, gitk
seems to work as-is with the new tcl, tk packages).
If anybody is interested, I can put the following packages up on the web
somewhere, but they'd need a little TLC before being "correct" and
"official" cygwin replacements for tcltk. For instance, the
"unversioned" packages ['tcl', 'tk', etc] contain the unversioned "wish
-> wish8.5.exe" symlinks and /usr/share/doc/ stuff. This should
probably all be merged into the "main" versioned package (tcl -> tcl8.5,
etc) and the 'unversioned' symlinks removed, being replaced by
postinstall scripts that use /usr/sbin/alternatives. Which would have
ripple effects on all the .hint files throughout.
Also, I noticed that debian packages itcl, itk, and iwidgets using only
${MAJ}, not ${MAJ}.${MIN} -- that is:
tcl8.5 + tk8.5, but
itcl3 + itk3 + iwidgets4
I don't know why, and I did it differently for itcl and itk. Fedora,
OTOH, doesn't use version numbers for ANY of these package -- just:
tcl + tk + itcl + itk + iwidgets
???
We should probably either do it debian's way, or Fedora's way, or be
self consistent and always use ${MAJ}.${MIN} -- my current weirdness is
mostly likely badly wrong. My gut says its safer to follow the others'
lead -- one or the other; and I prefer the debian way for reasons
explained below.
And the READMEs all still claim that cygwin-ports maintains them, even
tho Yaakov has nothing to do with these "forks" of his ports (and I'm
not volunteering to take over these packages; too much on my plate,
honestly. I'd suck as the maintainer).
tcltk 20080420-2 (empty upgrade helper)
tcl 8.5.7-1
tcl8.5 8.5.7-1
tcl8.5-devel 8.5.7-1
tcl8.5-doc 8.5.7-1
tk 8.5.7-1
tk8.5 8.5.7-1
tk8.5-demo 8.5.7-1
tk8.5-devel 8.5.7-1
tk8.5-doc 8.5.7-1
tcl 3.4b1-1
itcl3.4 3.4b1-1
itcl3.4-devel 3.4b1-1
itcl3.4-doc 3.4b1-1
itk 3.3-1
itk3.3 3.3-1
itk3.3-devel 3.3-1
itk3.3-doc 3.3-1
iwidgets 4.0.2-1
iwidgets4 4.0.2-1
iwidgets4-demo 4.0.2-1
iwidgets4-doc 4.0.2-1
[1] Corinna mentioned that, because the current tcltk DLLs are named
"libtcl84.dll" and "libtk84.dll", we might retain transitional
compatibility with un-recompiled python, insight, git, etc, by modifying
the "new" tcl and tk build process to use the standard cygwin naming
convention of 'cyg*.dll'. The modified build process for the
TEA-compliant extensions itcl, itk, and iwidgets DOES do this. However,
I did not modify my ports of tcl and tk -- because we already HAVE that
win: the new dlls are named
libtcl8.5.dll (vs. libtcl84.dll)
libtk8.5.dll (vs. libtk84.dll)
So, transitional compatibility can be maintained [2] simply by repacking
the existing tcltk package so that it installs the necessary runtime 8.4
runtime files and DLLs (instead of the *empty* upgrade helper). This
package would need careful auditing to make sure that it (a) doesn't
conflict with stuff provided by the "new" packages (e.g. probably
removing ALL of the development files, and the unversioned wish.exe,
tclsh.exe, and *Config scripts) and (b) does provide what is necessary
for the current non-rebuilt incarnations of ruby, python, git, expect,
and insight. It's possible that (a) and (b) might be mutually exclusive.
As far as changing further the build process of the new tcl and tk
packages to use the 'cyg' prefix -- it can be done, but it's probably
harder than just locating the correct spot in the makefile/configury.
This is because tcl and tk can by dynamically loaded, so changing the
DLL name might require other changes elsewhere in the .c code where
"lib" is assumed. I know this was true for the i* variants, but Yaakov
did the work there IIRC.
[2] No, it can't. Creating a tcltk package that contains only the
non-conflicting runtime files (that is, removing from the original tcltk
package the following):
usr/bin/tclsh.exe
usr/bin/wish.exe
usr/include/*.h
usr/lib/*.a
usr/lib/tclConfig.sh
usr/lib/tkConfig.sh
usr/man/mann/*
usr/share/iwidgets4.0.1/demos/*
usr/share/man/mann/*
usr/share/tk8.4/demos/*
doesn't seem to help insight. It launches (rather than dying due to
missing DLL), but then complains because it finds itcl-3.4 (the new X
version) and wants exactly itcl-3.2. I don't know why it is not locating
the itcl-3.2 package, which is right where it always was at
/usr/[lib|share]/itcl3.2/. Maybe tcl is smart, and seeing:
/usr/lib/itcl3.2/pkgIndex.tcl
/usr/lib/itcl3.4/pkgIndex.tcl
it loads always the newest one. Well, that's a bust. But, gitk works
as-is with both the new X-based wish8.5.exe and the old wish84.exe; I
just have to change the 'exec wish' (or modify the /usr/bin/wish
symlink) two switch between them. However, I begin to suspect that it
will be much more trouble than it is worth to keep a backward-compatible
version of tcltk(8.4) around. If tcltk8.4 requires recompilation to
change its extension search path so as not to be confused by the "new"
extensions that are compatible only with the new tcl and tk -- and this
recompilation may then require additional recompilation of the dependent
projects (python, ruby, etc) -- have we really gained anything? If we
have to recompile the dependent projects anway...might as well have 'em
use the 8.5-series (assuming that accepting the X11 requirement is still
ok, across the board).
Anyhoo, with the packages above installed, and the attached patch
against a source tree created by:
$ cvs -d:pserver:anoncvs@sourceware.org:/cvs/src co insight
$ cd src
$ rm -rf itcl
$ rm -rf tcl
$ rm -rf tk
$ <apply patch>
$ cd ..
The following build recipe seems to work:
$ mkdir _build
$ mkdir _inst && cd _inst && instdir=`pwd` && cd ..
$ cd _build
$ ../src/configure \
--prefix=/usr --sysconfdir=/etc --localstatedir=/var \
--enable-gdbtk --with-curses --with-libiconv-prefix=/usr \
--with-tcl=/usr/lib/tcl8.5 \
--with-tk=/usr/lib/tk8.5 \
--with-x \
--disable-werror # optional: --with-python [3]
$ make all-gdb info
$ make install install-libgui DESTDIR=${instdir}
I get gdb.exe, insight.exe, and gdbtui.exe which each weigh in at 20MB.
Unfortunately, using this build recipe, the gdb.exe and gdbtui.exe you
get have dependencies on the X libraries even if they don't actually use
them.
Turning the result into a cygwin-compliant installation package -- such
as removing files that conflict with the binutils package from the
installation tree, "splitting" into a gdb(no-x) and an insight package
(where presumably the former is the product of an entirely separate
configure/compile process) etc -- is left as an exercise. It works
in-place, tho -- so adding _inst/usr/bin to the front of PATH is fine.
[3] but only if you've also already rebuilt python with the new X-based tk.
> I'm really thinking that insight should be retired. I know the maintainer
> pretty well and he's not extremely keen on keeping it its current
> state.
Keith said:
http://sources.redhat.com/ml/insight/2009-q3/msg00035.html
that Insight 7.0 will be the last release of that codebase. He's also
said that he has dreams of one day rewriting a gui debugger based on
newer gdb facilities (with python? pyGTK?)
http://sourceware.org/gdb/wiki/PythonGdb
"It should be possible to rewrite Insight in Python."
But that's quite a lot of effort, and I don't see anybody jumping up and
down to get that done soon.
OTOH...there do already exist several other FOSS GDB front-ends that are
somewhat usable on cygwin/windows: there's
1) the Zylin Eclipse/CDT plugin, for "standalone" debugging. This has
nothing to do with cygwin, except that it can be used with cygwin's gdb
as the back end. It knows how to exploit cygpath to DTRT, since it
doesn't understand posix paths itself, being a native application.
2) Then you've got the KDE-based kdevelop, which is already ported to
cygwin/X over at the cygwin-ports project. I don't know how many
cygwin-ports (as opposed to stock cygwin) dependencies it has.
3) Cygwin-ports also has a version of the Gnome-based Anjuta. I don't
know how many cygwin-ports (as opposed to stock cygwin) dependencies it has.
4) And nemiver could probably also be ported, given our existing (stock
cygwin) GTK infrastructure...this might be the most lightweight approach
for a semi-official cygwin GDB frontend, but it's also the least mature.
(plus DDD, and Emacs GDB-mode)
As an aside, 'gdbtui' is kinda neat; I'd never used that before even
though it has long been part of cgf's gdb packages.
--
Chuck
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insight-20090915.patch
Type: application/x-patch
Size: 10275 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20090916/3989def4/attachment.bin>
-------------- next part --------------
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin
mailing list