Re: tcl/tk/expect/dejagnu/gdb/insight [Was: Re: [PATCH] Define _TIMEVAL_DEFINED consistently whenever defining timeval.]

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Dave Korn wrote:
> Yaakov (Cygwin/X) wrote:
> 
>>> which, honestly, isn't very much. I'd be concerned about all those
>>> tcl-db${old_version} packages -- but it looks like there are no
>>> in-distro users of them.  That leaves gdb, ruby, python, git, and parrot
>>> -- all of which have active maintainers.  Plus suite3270 and brltty,
>>> which I'm not sure about.
>> I see no plausible way to transition other than a simultaneous release
>> of all these packages.

Weeeeelllll, we did adopt the WJM policy for the cygwin-1.7/gcc4/dw2 DLL
transition: http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html
>> #3) if some app does break, it's up to that app's maintainer to rebuild
>> as needed, NOT the DLL maintainer to ensure backwards compatibility,
>> even though per #1 he has re-used the existing DLL number.
>> #4) BUT no need to coordinate all of these rebuilds -- if any are
>> required -- on some sort of official flag day.
Not exactly what that particular get-out-of-jail-free card was meant
for, but...

> Could we conceivably do coexistence by bringing in the new properly
> cygwinized versions at version 8.5 and keep the current 8.4 DLLs and
> /usr/share files around for backward compat?

I tested that already. It seems to work okay with gitk and python (idle).

Dunno about ruby -- ruby apparently dynamically loads extension
libraries, because neither the DLL nor the EXEs are linked directly to,
e.g. the iconv dll or the tcl/tk dlls.  However, its configure script
has "--with-tcl" and "--with-tk" options, but no "--with-itcl" or
"--with-itk" so I suspect we're "safe" there, as well.

I believe that expect is tk-agnostic, and so would be unaffected by the
switchover -- except as much as any client might notice if its
underlying interpreter jump a minor version number.

However, even though the *files* do not appear to conflict, somehow
*old* tcl finds the *new*  itcl -- which causes *current* insight to
complain.

Now, as far as I know, *only* gdb uses itcl/itk/iwidgets. All of the
other dependent tools use directly tcl and tk, nothing more.

Hence, your proposal would probably work for everything *but* insight.

For insight there are three choices, as I see it:

1) abandon insight completely (cgf's preferred solution?)

2) /opt/insight/ with its own local version of insight.exe + tcl + tk +
itcl + itk + iwidgets.  So, we'd keep the (modified) tcltk runtime-only
package, and you'd have up to three different copies of the tcl and tk
DLLs: two 8.4 versions -- one in /usr and another in /opt/insight, and
one 8.5 version in /usr.

3) Rebuild insight to use the new X versions of tk/itk/etc. In this case
we'd also keep the (modified) tcltk runtime-only package, for backwards
compatibility for those clients -- other than insight -- for which this
solution works.



I've made a build of insight according to #2.  It needs the patch which
started this whole thread:
  http://cygwin.com/ml/cygwin-patches/2009-q3/msg00075.html
as well as the attached patch (which is very hackish) against 20090916
insight cvs. To recreate, do this:

$ cvs -z3 -d :pserver:anoncvs@sourceware.org:/cvs/src co \
	-D 2009-09-16 insight
$ cd src
$ <apply patch>
$ cd ..
$ mkdir _build
$ cd _build
$ <invoke buildscript>

If we go that route, the buildscript can be easily imported to mknetrel
format. The advantage of this approach is it can be done before any
thing else, and deployed in advance of any destabilizing changes, and it
should just work. (Famous Last Words)



As I mentioned in a different message, #3 also involves some excessive
hackery.

--
Chuck

Attachment: insight-native-patch-and-buildscript.tar.bz2
Description: Binary data

--
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