Message-ID: <4AD07042.30509@cwilson.fastmail.fm>
Date: Sat, 10 Oct 2009 07:30:10 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gdb, insight, and tcltk
References: <4ACD0C50 DOT 2010902 AT cwilson DOT fastmail DOT fm>  <4ACE3545 DOT 7070904 AT cwilson DOT fastmail DOT fm> <20091008212311 DOT GA2068 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20091008212311.GA2068@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Christopher Faylor wrote:
> I'm sorry.  I haven't been giving this my full attention since I have a
> working version of gdb and insight and thought you were asking insight
> questions.

'salright.

> I'm wondering if it would just be best for me to continue in this vein.
> It probably won't be worthwhile to be splitting responsibilities
> because, frankly, I REALLY don't want to be debugging your end of things
> along with my own.  This probably sounds mean but I don't mean it to be.
> I just don't want to have to devote double the amount of brain power to
> figuring out my own gdb issues along with yours and then coordinating
> with you every time I find a problem.

Fair enough. I was anticipating only minimal interaction, after this
initial hurdle -- basically, I'd've grabbed whatever patches you were
using for gdb-7.0 and otherwise stayed out of your hair.  However, right
now I am^H^Hwas trying to go /first/, so that route wasn't available.
And, if the two packages, "gdb" vs. "insight" were installed into
separate prefixes (so they /couldn't/ share files like
'share/gdb/syscalls/gdb-syscalls.dtd' even if they wanted to) then there
would be/is no reason for the two packages to "synchronize" their
releases at all.

In fact, I think that's what you ought to do, anyway, for a number of
reasons, detailed below. But first, an aside:

I think I've solved the tcltk problem in a way that makes everybody
happy.  By recompiling exactly the tcltk-20080420 source code, with
different --includedir and --libdir options, I've managed to create a
new tcltk package that:

  1) allows current clients -- like the *existing* insight from
     gdb-6.8-2 -- to keep working without change, even if you install
     X-based versions of the tcl/tk/itcl/itk/iwidgets.

  2) constructed an alternatives-based scheme for the tcltk
     "back-compat" package and new X-based tcl/tk/itcl/itk/iwidgets
     packages, so that users can switch the 'tclsh.exe', 'wish.exe',
     and various development files as desired.  This affects clients
     like gitk -- which is happy with either the win32ish wish84, or
     with the Xish wish8.5.  However, insight(6.8-2) itself uses the
     tcl84.dll library directly, so mucking with wish.exe makes no
     difference to it; it STAYS win32ish.

With a whole slew of Xish tcl/tk packages installed, this new version of
tcltk-20080420 installed, and the alternatives set to prefer the "old"
versions, gitk and python(idle) are both happy. (And of course,
insight(6.8-2) is happy).  Plus, the X-based versions work great, too,
installed alongside. (gitk is even happy if you switch the alternatives
to the new Xish versions. python, not so much. But the workaround is for
folks to run 'set-tcltk-old', and stay that way, until the maintainers
of all the clients EXCEPT insight rebuild).


So, that's great if we never again try to update tcltk or insight.
But...that ain't the case.  So...if you (Chris) want to allow the rest
of the distro to switch to using X-based tcl/tk&friends, then there are
couple of approaches you could take with the new version of insight/tcltk.

Option 1: separately, and *independently*, build tcltk-win32 and
insight/gdb.  In this case, you build and install the tcltk(old,
win32ish) software into /usr as a separately built package -- and then
get rid of the build and src directory.  When building insight, you do
NOT use the current method(s) of accessing the tcltk internals.
   a) NOT: access the "tcltk source tree" via netrel/a/b/c/gdb/../tcltk/
      This is how the existing netrel build procedure works for
      gdb/insight.
   b) NOT: access the in-tree tcltk source code "inside" the gdb source
      tree.
Instead, you need to use the newly added "external tcl/tk libs" support.
It's just that the "external" libs are the ones built exactly FROM the
same source in the sourceware repository.

The drawback to this approach is that you keep having to maintain a
so-called "tcltk" package, each time you update insight (if ever). IF
were trying to obsolete the old win32ish tcltk, this doesn't make any
sense.  Obsolete == frozen.  Or it should.  Plus, intermingling "gdb"
and "insight" under the same prefix is icky -- especially when gdb
continues on towards 8.0, 9.0, and beyond, and insight remains stuck at
7.0...

2) Category 2: Build insight using the in-tree tcltk, BUT install the
whole schmeil, tcltk and all, into /opt/somewhere.  Call it "insight"
not "gdb". This has several advantages:
   a) the "back-compat" tcltk in /usr is just that: back compat only.
      Never again needs any updating.  It won't be used by the (newer)
      /opt/somewhere-installed insight.  And all OTHER current tcltk
      clients, unlike insight, can, should, and will, transition to
      using the new Xish versions. (But in the interim, can keep workin)
   b) insight will be able to use exactly the version of the tcl/tk libs
      that it has been tested with upstream.  (e.g current HEAD has a
      newer version of itcl than the 20080420 snapshot.  This is why I
      did NOT create my back-compat tcltk package from current HEAD --
      I wanted to make sure that I changed /nothing/ underneath the
      existing clients. (The rebuild moved some files in tcltk around,
      but *external* clients don't care about those sorts of changes).
      But if insight NEEDS the newer itcl...we're right back where we
      started, unless you just punt and install insight
      /opt/elsewhere-else.
   c) by installing insight into a prefix other than the one used by gdb
      proper, we can (eventually) let insight-7.0 languish in
      /opt/obscurity while preparing gdb-7.1, gdb-8.0, -9.0, etc.  Since
      Kieth has already made it clear that while gdb development is
      ongoing, insight development will halt completely after the
      release of version 7.0.  We need to ensure that files which are
      nominally "shared" between gdb and insight, such as
          'share/gdb/syscalls/gdb-syscalls.dtd'
      don't conflict as gdb marches on (and insight doesn't).
   d) If insight is in /opt/overthere, it becomes clear that it is an
      add-on, an afterthought.  Not as aggressively maintained as
      gdb.  etc.
   e) Finally, by having entirely separate builds -- rather than one
      combined build and simply splitting pieces out for a 'gdb' pacakge
      and an 'insight' addon, you can have a leaner and meaner gdb.
      (gdb.exe 6.8-2 depends on tk84.dll...)

So, I encourage you to go with option 2.  In fact, I've put together a
cygport that does exactly that.  Take it with my blessings (of course,
cygports are a native-only, not cross-build, phenomenon, so you'll
probably just adapt what's there to a new netrel scriptlet).


However, for the /rest/, I think we can deploy those almost immediately,
whether you go Option 1 or Option 2.

tcltk-20080420-update
tcl8.5    [8.5.7]
tk8.5     [8.5.7] (Xish)
itcl3     [3.4b1]
itk3      [3.3]   (Xish)
iwidgets4 [4.0.2] (Xish)


All of these packages, plus a version of insight (win32ish) that
installs into /opt/insight (insight-7.0pre_20091006), are available as a
setup repo here:
    http://cygutils.fruitbat.org/tcltk/
I don't have a gpg key, so you'll need to either download locally or run
setup with -X.  The md5sum of the setup-2.ini file is:
    64d140156b2837945dcc145b424b78f9
Since setup-2.ini contains md5sums of all the tarballs, that should be
sufficient to verify integrity even for the paranoid.

So, Chris, if you want to go option 2, then I'm still willing to "take
over" the (what would then be) obsolete tcltk package, and to ITP the
X-based replacements.  option 1, it gets tricky,...

--
Chuck

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