This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Insight, Source-Navigator, Tcl/Tk, and you
- To: insight at sources dot redhat dot com, sourcenav at sources dot redhat dot com
- Subject: Insight, Source-Navigator, Tcl/Tk, and you
- From: Syd Polk <spolk at redhat dot com>
- Date: Mon, 23 Oct 2000 13:02:49 -0700
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