Insight, Source-Navigator, Tcl/Tk, and you

[Syd Polk <spolk at redhat dot com>]

There has been much discussion about Insight, Source-Navigator, Tcl/Tk and 
packaging on both the Insight and Source-Navigator lists recently. I 
thought I would lay out the state of the world to the list, and solicit 
feedback.

Introduction

Both Insight and Source-Navigator started life integrated in the old Cygnus 
build tree. This build tree has local versions of Tcl, Tk, Tix, incr Tcl, 
dejagnu, and expect.

One of the primary reasons is that the Cygnus build tree is designed for a 
cross-development environment. This means that it can compile binaries for 
another OS than the one the compile is running on. So, I can build a 
compiler and debugger which run on linux but generate code for an arm 
processor. I can build them to run on Windows and generate code for an arm 
processor. I can generate a compiler which runs on Linux and compiles for 
Windows. I can even generate a compiler which runs on windows, generates 
code for arm, and built it on Linux.

Tcl/Tk, as it is distributed, does not have the necessary changes in 
configure to allow this to happen.

Also, previous Cygnus products (which are no longer being supported) added 
features to Tcl/Tk which the maintainers did not accept, for whatever reasons.

So we ended up with a divergent tree.

Tcl/Tk and gcc

gcc is dependent on tcl because it uses dejagnu and expect to run the test 
suite.

Tcl/Tk and gdb

gdb is dependent on tcl for the same reason.

Tcl/Tk and Insight or Source-Navigator

This should be obvious.

The mainline tcl code in our build tree is Tcl 8.0.5, Tk 8.0.5, and incr 
Tcl 3.0. There are many modifications to the code, particularly in the 
configure files and Makefiles to support automated testing and building on 
various platforms, including cross-compiling.

Source-Navigator diverges from this because we did a Japanese release in 
early 1999. We had to upgrade our tcl version to some derivative of Tcl 
8.1, which we did. This caused an internal divergence, but we were able to 
handle it. At the time, we used Tcl 8.1b1. At this time also, however, the 
mainline Tcl/Tk tree was using incrTcl 1.5, hacked by us to support 
namespaces. Source-Navigator 4.5.2 still uses incr Tcl 1.5. It was decided 
at the time that upgrading the rest of the Tcl versions to 8.1 would have 
to wait until there was more time.

At some point, gdb's cvs archive was put onto sources.redhat.com. The 
version of tcl, tk, and incr Tcl that Insight uses was checked into this 
archive.

So there are several goals that we have for this stuff:

- We want to use one version of Tcl/Tk for everything.
- We would prefer to use Tcl/Tk that is included with the user's setup if 
at all possible, but we have to be prepared to provide our own versions if 
the user does not have one or if it is the incorrect version. This is 
actually a customer requirement; we cannot force the customer to upgrade 
the version if he or she has the wrong one.
- We have to be able to build and run the test suites for gcc, gdb, and 
Source-Navigator from one source tree. This is not trivial because regular 
expressions changed between Tcl 8.1 and 8.2, and we have to update the more 
than 100000+ tests to the new syntax. While it is expected that only 1 in 
1000 tests might be affected, that still leaves 100 tests. And they have to 
be tested on all popular platforms, including embedded targets.

What are we doing about it?

- What I am doing about it is I am upgrading our build tree to be unified.
- I will then submit patches to the Tcl maintainers so that their tree and 
ours have a minimal number of differences.
- After that, I will update sources.redhat.com
- After that, I will put the Source-Navigator cvs tree on sources.redhat.com.

Why I will not support packages generated by the community:

Neither gdb nor source-navigator has been adequately tested on any new 
versions of Tcl/Tk. They both were designed to encapsulate their own 
versions of Tcl/Tk. We are trying to change that, but it is slow.

All of the open source packaging schemes I have seen rely on the 
distribution version of Tcl/Tk.  While things may appear to work initially 
with these version of Tcl/Tk, I really prefer to have at least the base gdb 
test suites run with this version of Tcl/Tk and against our version and any 
differences between the two accounted for.

At some point when all of this work is complete, we will be posting RPMs 
for Red Hat Linux, and we may post packages in other formats as well.

This is a lot of work, and it is really hard to delegate out.

What can you do?

Submit patches back to these lists which help make the job easier. If you 
have managed to get things to compile and work on later versions of Tcl, 
try to make it work on the distribution version of Tcl and the one we ship 
simultaneously, with #ifdef in C code, or comparisons to the tcl_version 
variable in Tcl code. Once the unification is done, we can remove the 
support for older versions.

I am sorry this is so long-winded, but it is important, and these are real 
issues which have to be dealt with. I am sorry I have not adequately 
explained the position before now.

Syd Polk
Insight and Source-Navigator maintainer