Tcl/Tk 8.3 upgrade...

Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

Hi,

so I've been making progress on the Tcl/Tk upgrade, gdb/gdbtk
was relatively plainless (ok, but who do I talk to about
expect...).

So there is only one more gdbtk testsuit failure with tcl/tk 8.3
than with the current tcl/tk version:    

   gdb.gdbtk/srcwin.exp: variable balloon test (srcwin-5.1)

Are they any "how to reproduce" steps for the tests?  I tried what
I thought the test was checking for (hold the mouse pointer
over a variable and wait to see the balloon containing the variables
value), but this worked, so I don't really know why this test is
failing.

The other problem with gdbtk is that it's using a hacked
tcl_findLibrary.  I've got two solutions to this problem:

 1) Rename the current tcl_findLibrary to gdb_findLibrary and 
 put it somewhere else.

 2) Forget the hacked tcl_findLibrary and rename the gdbtk installed
 library directory from ".../share/gdbtcl" to ".../share/gdb1.0". This
 what I had been doing until I found out about the hacked tcl_findLibrary.

There is also the option of just using the hacked tcl_findLibrary
proc as we currently do, but I'd really like to see us do away with
the local Cygnus changes, slowly moving towards the goal of running
with pre-installed Tcl/Tk versions.

Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Keith Seitz]

On Tue, 12 Jun 2001, Ian Roxborough wrote:

> so I've been making progress on the Tcl/Tk upgrade, gdb/gdbtk
> was relatively plainless (ok, but who do I talk to about
> expect...).

Bwaaa haaa haaa. Good question... Don Libes?

> So there is only one more gdbtk testsuit failure with tcl/tk 8.3
> than with the current tcl/tk version:
>
>    gdb.gdbtk/srcwin.exp: variable balloon test (srcwin-5.1)

Does it produce a tcl error or just report some dorky number? You may have
to manually type in the test. The srcwin tests are notoriously bad... All
of our tests are NOT supposed to presume that previous tests have run,
but, alas, this practice is not widely adhered to.

I would recommend running the test by hand. Load insight, and look up the
proc do_test in util.tcl. You can specify the filename and the particular
test to run.

If all else fails, do what I do: run the test, but put messageboxes and
sleeps around the test to isolate it and see what is going on... :-)

> Are they any "how to reproduce" steps for the tests?  I tried what
> I thought the test was checking for (hold the mouse pointer
> over a variable and wait to see the balloon containing the variables
> value), but this worked, so I don't really know why this test is
> failing.

The variable balloon tests use a function in libgui to warp the cursor.
Perhaps this no longer works...

> The other problem with gdbtk is that it's using a hacked
> tcl_findLibrary.  I've got two solutions to this problem:
>
>  1) Rename the current tcl_findLibrary to gdb_findLibrary and
>  put it somewhere else.
>
>  2) Forget the hacked tcl_findLibrary and rename the gdbtk installed
>  library directory from ".../share/gdbtcl" to ".../share/gdb1.0". This
>  what I had been doing until I found out about the hacked tcl_findLibrary.

Are we really replacing the call to tcl_findLibrary in Tcl? Ouch... Well,
I understand WHY we are doing it (so that we can run from the build
directory), but there must surely be better ways to do it.

In either case, I don't like using the name "gdb1.0". If you go this
route, please use insight1.0 or gdbtk1.0. I am already considering
"purifying" the gdb repository by taking insight out and teaching gdb how
to deal with other toplevel UIs.

Keith

Re: Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

On Tue, 12 Jun 2001 18:18:30 -0700 (PDT)
Keith Seitz <keiths@cygnus.com> wrote:

> On Tue, 12 Jun 2001, Ian Roxborough wrote:
> >    gdb.gdbtk/srcwin.exp: variable balloon test (srcwin-5.1)
>
> If all else fails, do what I do: run the test, but put messageboxes and
> sleeps around the test to isolate it and see what is going on... :-)
> 
> > Are they any "how to reproduce" steps for the tests?  I tried what
> > I thought the test was checking for (hold the mouse pointer
> > over a variable and wait to see the balloon containing the variables
> > value), but this worked, so I don't really know why this test is
> > failing.
> 
> The variable balloon tests use a function in libgui to warp the cursor.
> Perhaps this no longer works...

Hmmm, I'll keep that in mind when looking for the problem.
 
> Are we really replacing the call to tcl_findLibrary in Tcl? Ouch... Well,
> I understand WHY we are doing it (so that we can run from the build
> directory), but there must surely be better ways to do it.

This isn't needed to run the gdbtk testsuit.  All I needed to do was add
a setenv ITK_LIBRARY to get gdbtk and the testsuit running from the build
directory.  This is problem there for some reason that left the code a few
years ago.

> In either case, I don't like using the name "gdb1.0". If you go this
> route, please use insight1.0 or gdbtk1.0.

Yeah.  I was purely basing the name on the library name and parameters
passed to tcl_findLibrary.  It was mangling them to gdb1.0, I think
something like .../share/gdbtk1.0 would be more appropriate.

So, I'll make these changes into a patch and get back to you guys.
(Hey, I guess I should test it on something else other than linux ppc
as well.)

Thanks,

  Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Andrew Cagney]

> Are we really replacing the call to tcl_findLibrary in Tcl? Ouch... Well,
> I understand WHY we are doing it (so that we can run from the build
> directory), but there must surely be better ways to do it.
> 
> In either case, I don't like using the name "gdb1.0". If you go this
> route, please use insight1.0 or gdbtk1.0. I am already considering
> "purifying" the gdb repository by taking insight out and teaching gdb how
> to deal with other toplevel UIs.


For what it is worth, me creating the directory src/gdb/gdbtk instead of 
src/gdb/insight is one of those things I'm going to regret for the rest 
of my life :-)  The move src/gdb/gdbtk -> src/insight will fix it though.

	Andrew

Re: Tcl/Tk 8.3 upgrade...

[Keith Seitz]

On Wed, 13 Jun 2001, Andrew Cagney wrote:

> > Are we really replacing the call to tcl_findLibrary in Tcl? Ouch... Well,
> > I understand WHY we are doing it (so that we can run from the build
> > directory), but there must surely be better ways to do it.
> >
> > In either case, I don't like using the name "gdb1.0". If you go this
> > route, please use insight1.0 or gdbtk1.0. I am already considering
> > "purifying" the gdb repository by taking insight out and teaching gdb how
> > to deal with other toplevel UIs.
>
>
> For what it is worth, me creating the directory src/gdb/gdbtk instead of
> src/gdb/insight is one of those things I'm going to regret for the rest
> of my life :-)  The move src/gdb/gdbtk -> src/insight will fix it though.

Yeah... I try my best to use "insight", but it just comes out "gdbtk".
"Codenames" are hard to kill...

Keith

Re: Tcl/Tk 8.3 upgrade...

[Mo DeJong]

On Tue, 12 Jun 2001, Keith Seitz wrote:

> > Are they any "how to reproduce" steps for the tests?  I tried what
> > I thought the test was checking for (hold the mouse pointer
> > over a variable and wait to see the balloon containing the variables
> > value), but this worked, so I don't really know why this test is
> > failing.
> 
> The variable balloon tests use a function in libgui to warp the cursor.
> Perhaps this no longer works...

One thing to note is that the built in cursor warping (using
the event comment) now works for both Windows and Unix with
Tk 8.3. We should no longer need local hacks to make it work.

Mo

Re: Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

On Tue, 12 Jun 2001 18:18:30 -0700 (PDT)
Keith Seitz <keiths@cygnus.com> wrote:
> Are we really replacing the call to tcl_findLibrary in Tcl? Ouch... Well,
> I understand WHY we are doing it (so that we can run from the build
> directory), but there must surely be better ways to do it.

OK, so after some more testing I found that my fix doesn't let you
run Insight from the build directory without setting the environment
variables: GDBTK_LIBRARY, ITCL_LIBRARY, ITK_LIBRARY, TCL_LIBRARY,
TIX_LIBRARY and TK_LIBRARY to point to the respective library directories
in the source tree. (Actually, using the current cvs version
of Tcl/Tk will only need GDBTK_LIBRARY set, due to the extra majic
in tcl_findLibrary will search the source directorys anyway.)

The testsuits run find as they set all the *_LIBRARY variables before
running gdb.

I guess running gdb in the build directory helps speed up development (no
install time).  The simplest fix is to use a script to launch gdb
when running it in the build directory.

Another fix is to switch and rename the hacked tcl_findLibrary with
the real tcl_findLibrary, so we don't rely on the hack being in
the Tcl version.

Another fix is to "detect" (if <gdb executablr dir> + gdb-tk.o = true...?)
if we are in the build directory then set the required
*_LIBRARY variables as needed.

If desired we can bring the hacked tcl_findLibrary in the Tcl8.3
version, but I'd like to avoid doing that.

> In either case, I don't like using the name "gdb1.0". If you go this
> route, please use insight1.0 or gdbtk1.0. I am already considering
> "purifying" the gdb repository by taking insight out and teaching gdb how
> to deal with other toplevel UIs.

I used insight1.0 as the replacement name for the gdbtcl directory.

Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Keith Seitz]

On Thu, 14 Jun 2001, Ian Roxborough wrote:

> Another fix is to switch and rename the hacked tcl_findLibrary with
> the real tcl_findLibrary, so we don't rely on the hack being in
> the Tcl version.
>
> Another fix is to "detect" (if <gdb executablr dir> + gdb-tk.o = true...?)
> if we are in the build directory then set the required
> *_LIBRARY variables as needed.

I'll vote for losing the hacked tcl_findLibrary, and using some heuristic
for determining if we are running in the build dir. Anything to prevent us
from modifying Tcl/Tk/tix/itcl/etc.

> I used insight1.0 as the replacement name for the gdbtcl directory.

main.tcl does a "package require gdbtk 1.0" and gdbtk.c defines the
package "gdbtk". I would change these all to "insight". I might even
consider bumping the version to differentiate this Tcl8.3-compatible
version from the older one. (Especially since we are going to be ripping
gdb and insight apart...)

Thank you for all your work in this area. I'm sure that there are many
people anxious to see the outcome of all your diligence!
Keith

Re: Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

On Thu, 14 Jun 2001 08:27:52 -0700 (PDT) Keith Seitz <keiths@cygnus.com> wrote:
> On Thu, 14 Jun 2001, Ian Roxborough wrote:
> 
> > Another fix is to switch and rename the hacked tcl_findLibrary with
> > the real tcl_findLibrary, so we don't rely on the hack being in
> > the Tcl version.
> >
> > Another fix is to "detect" (if <gdb executablr dir> + gdb-tk.o = true...?)
> > if we are in the build directory then set the required
> > *_LIBRARY variables as needed.
> 
> I'll vote for losing the hacked tcl_findLibrary, and using some heuristic
> for determining if we are running in the build dir. Anything to prevent us
> from modifying Tcl/Tk/tix/itcl/etc.

I'm finding yet more and more local changes to Tcl to make it play nicely
with Insight running from the build directory (the ones for launching
Tcl in tclInitScript.h).

Is anybody going to mind if I install a script at build time to run
gdb out of the build directory.  Maybe call it run-insight.sh or something.
Everything works other than typing ./gdb in the build directory,
I'm not sure if this is worth all the code changes vs. a 7 line
shell script.

It looks like it would be a good idea to revisit how Insight is
being launched, making SN location independant made a lot of things
easier (I was noticing that if I rename my install dir Insight doesn't
work any more).  But this is probably outside of the scope the Tcl/Tk
upgrade.

> > I used insight1.0 as the replacement name for the gdbtcl directory.
> 
> main.tcl does a "package require gdbtk 1.0" and gdbtk.c defines the
> package "gdbtk". I would change these all to "insight". I might even
> consider bumping the version to differentiate this Tcl8.3-compatible
> version from the older one. (Especially since we are going to be ripping
> gdb and insight apart...)

I'm hoping for very few changes to Insight.  Although, by changing
the gdbtk to insight effectively changes the version.

Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Keith Seitz]

On Thu, 14 Jun 2001, Ian Roxborough wrote:

> I'm finding yet more and more local changes to Tcl to make it play nicely
> with Insight running from the build directory (the ones for launching
> Tcl in tclInitScript.h).

:-(

> Is anybody going to mind if I install a script at build time to run
> gdb out of the build directory.  Maybe call it run-insight.sh or something.
> Everything works other than typing ./gdb in the build directory,
> I'm not sure if this is worth all the code changes vs. a 7 line
> shell script.

I wouldn't like that, to be honest. That would mean I would have to
install insight before I can debug it... That's not very developer
friendly. What other problems are you hitting?

> It looks like it would be a good idea to revisit how Insight is
> being launched, making SN location independant made a lot of things
> easier (I was noticing that if I rename my install dir Insight doesn't
> work any more).  But this is probably outside of the scope the Tcl/Tk
> upgrade.

I am playing with configury/automake for insight. This will completely rip
insight out of the gdb directory. Alas, it is very complicated. I will
need to test this on a great many machines before I can check it in.

Keith

Re: Tcl/Tk 8.3 upgrade...

[Fernando Nasser]

Keith Seitz wrote:
> 
> On Thu, 14 Jun 2001, Ian Roxborough wrote:
> 
> > I'm finding yet more and more local changes to Tcl to make it play nicely
> > with Insight running from the build directory (the ones for launching
> > Tcl in tclInitScript.h).
> 
> :-(
> 
> > Is anybody going to mind if I install a script at build time to run
> > gdb out of the build directory.  Maybe call it run-insight.sh or something.
> > Everything works other than typing ./gdb in the build directory,
> > I'm not sure if this is worth all the code changes vs. a 7 line
> > shell script.
> 
> I wouldn't like that, to be honest. That would mean I would have to
> install insight before I can debug it... That's not very developer
> friendly. What other problems are you hitting?
> 

Yes, we must run Insight from the build directory.

Also, how would this affect testsuite runs?

Note that if we make insight's own main.c we can add some code to handle these situations.

> > It looks like it would be a good idea to revisit how Insight is
> > being launched, making SN location independant made a lot of things
> > easier (I was noticing that if I rename my install dir Insight doesn't
> > work any more).  But this is probably outside of the scope the Tcl/Tk
> > upgrade.
> 
> I am playing with configury/automake for insight. This will completely rip
> insight out of the gdb directory. Alas, it is very complicated. I will
> need to test this on a great many machines before I can check it in.
> 

Keith,

This will make it forever impossible for us to use any of the target configuration parameters that are set and available under the src/gdb directory hierarchy.

This means that we can only get information by adding a command to read the gdb "arch" stuff (I wonder if that is _all_ the information about targets -- but I guess one can propose and add anything that is missing).

I do have a couple of versions of Insight that cannot go into the main sources because they have some widgets and a few other things that are specific to the target.  We will need to establish the "official" way to test for architecture/target in the insight code.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Tcl/Tk 8.3 upgrade...

[Mo DeJong]

On Thu, 14 Jun 2001, Ian Roxborough wrote:

> On Thu, 14 Jun 2001 08:27:52 -0700 (PDT) Keith Seitz <keiths@cygnus.com> wrote:
> > On Thu, 14 Jun 2001, Ian Roxborough wrote:
> > 
> > > Another fix is to switch and rename the hacked tcl_findLibrary with
> > > the real tcl_findLibrary, so we don't rely on the hack being in
> > > the Tcl version.
> > >
> > > Another fix is to "detect" (if <gdb executablr dir> + gdb-tk.o = true...?)
> > > if we are in the build directory then set the required
> > > *_LIBRARY variables as needed.
> > 
> > I'll vote for losing the hacked tcl_findLibrary, and using some heuristic
> > for determining if we are running in the build dir. Anything to prevent us
> > from modifying Tcl/Tk/tix/itcl/etc.
> 
> I'm finding yet more and more local changes to Tcl to make it play nicely
> with Insight running from the build directory (the ones for launching
> Tcl in tclInitScript.h).
> 
> Is anybody going to mind if I install a script at build time to run
> gdb out of the build directory.  Maybe call it run-insight.sh or something.
> Everything works other than typing ./gdb in the build directory,
> I'm not sure if this is worth all the code changes vs. a 7 line
> shell script.

Why don't we setup things so that running "make gdb" runs the
executable in the build directory. That way, we could set the
TCL_LIBRARY env var before running gdb in the build dir. That
is how tclsh is run out of the build directory. We should stick
with something simple instead of hacking the source code
to support running in the build dir (if possible).
 
Mo DeJong
Red Hat Inc

Re: Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

On Thu, 14 Jun 2001 18:49:36 -0400
Fernando Nasser <fnasser@cygnus.com> wrote:
> Yes, we must run Insight from the build directory.

And that wouldn't be an issue.  It would still run, just
a script (put in the build directory at make or configure
time) would set some environment variables and run gdb.

> Also, how would this affect testsuite runs?

This shouldn't affect the testsuites. They run fine.
 
> Note that if we make insight's own main.c we can add some code
> to handle these situations.

Yeah, I see that.  We can make this set TCL_LIBRARY, etc. before
it tries any *_inits and everything should work.

Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

On Thu, 14 Jun 2001 15:33:54 -0700 (PDT)
Keith Seitz <keiths@cygnus.com> wrote:

> On Thu, 14 Jun 2001, Ian Roxborough wrote:
> 
> > I'm finding yet more and more local changes to Tcl to make it play nicely
> > with Insight running from the build directory (the ones for launching
> > Tcl in tclInitScript.h).
> 
> :-(

Yeah, everything look great until I found these hacks.

> > Is anybody going to mind if I install a script at build time to run
> > gdb out of the build directory.  Maybe call it run-insight.sh or something.
> > Everything works other than typing ./gdb in the build directory,
> > I'm not sure if this is worth all the code changes vs. a 7 line
> > shell script.
> 
> I wouldn't like that, to be honest. That would mean I would have to
> install insight before I can debug it...

No it wouldn't, it would mean that when you do a build it puts script
call run-insight.sh in the build directory, instead of typing ./gdb
you type ./run-insight.sh.  All the script is doing is settting
the correct *_LIBRARY before running gdb.

You wouldn't have to do an install just to run insight from the build
directory.  I'm trying to avoid disturbing people's normal development
style.

Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Fernando Nasser]

Ian Roxborough wrote:
> 
> On Thu, 14 Jun 2001 18:49:36 -0400
> Fernando Nasser <fnasser@cygnus.com> wrote:
> > Yes, we must run Insight from the build directory.
> 
> And that wouldn't be an issue.  It would still run, just
> a script (put in the build directory at make or configure
> time) would set some environment variables and run gdb.
> 
> > Also, how would this affect testsuite runs?
> 
> This shouldn't affect the testsuites. They run fine.
> 

The gdb testsuites.  But I bet the gdbtk tests will not (will at least
need some adjustments).



> > Note that if we make insight's own main.c we can add some code
> > to handle these situations.
> 
> Yeah, I see that.  We can make this set TCL_LIBRARY, etc. before
> it tries any *_inits and everything should work.
> 

Exactly.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Tcl/Tk 8.3 upgrade...

[Ian Roxborough]

On Fri, 15 Jun 2001 09:32:30 -0400
Fernando Nasser <fnasser@redhat.com> wrote:

> Ian Roxborough wrote:
> > 
> > On Thu, 14 Jun 2001 18:49:36 -0400
> > Fernando Nasser <fnasser@cygnus.com> wrote:
> > > Also, how would this affect testsuite runs?
> > 
> > This shouldn't affect the testsuites. They run fine.
> 
> The gdb testsuites.  But I bet the gdbtk tests will not (will at least
> need some adjustments).

I bet you they do.  The only adjustment that I made to
get the gdbtk testsuit running was setting ITK_LIBRARY.
They are hacks in the current cvs version of Tcl which
munge out the ITCL/ITK pathes to find the source directory.

Just incase I've not been clear:

- running gdb and gdbtk from the install directory works fine.

- running gdb and gdbtk testsuites from the build directory
  works fine.

- running gdb from the build directory works.

The only think that didn't work is running gdbtk from the
build directory without setting the *_LIBRARY environment
variables.

> > > Note that if we make insight's own main.c we can add some code
> > > to handle these situations.
> > 
> > Yeah, I see that.  We can make this set TCL_LIBRARY, etc. before
> > it tries any *_inits and everything should work.
> > 
> 
> Exactly.

Yeah, I've done that. Still don't like it much, but that's
just me (chance to remove some code as well as keeping the
code to run gdb from the build directory in the build, slightly
smaller binary, etc.).  

What I've added will now check to see if gdb has been ran
from a "bin" directory.  If not and TCL_LIBRARY isn't set,
then it will set TCL_LIBRARY and then run a short embedded
Tcl script to set the other *_LIBRARY before going on to
start Insight.

You could also use this code to try and solve some of gdbtk's
location independance problems.


OK, so I've now got all the bits running the way you guys
have requested, I need some time to put this all together
and do some testing/code clean up/etc..  So hopefully
some time next week I'll submit a patch removing the need
from the Tcl local changes and renaming the gdbtk directory
to insight1.0.

Is there any chance of major changes over that time?
When are you planning to split gdb and insight in to
seperate modules?


Thanks,
  Ian.
-- 
What would Jenna Bush do?

Re: Tcl/Tk 8.3 upgrade...

[Keith Seitz]

On Fri, 15 Jun 2001, Ian Roxborough wrote:

> I bet you they do.  The only adjustment that I made to
> get the gdbtk testsuit running was setting ITK_LIBRARY.
> They are hacks in the current cvs version of Tcl which
> munge out the ITCL/ITK pathes to find the source directory.

Yes, the testsuite should still run, even from the build directory. I went
to great pains to do this. The dejagnu infrastructure will set all the
*_LIBRARY environment variables. AFAIK, this is all that needs to be done.

> The only think that didn't work is running gdbtk from the
> build directory without setting the *_LIBRARY environment
> variables.

Well, I can think of another way to do it using your "run-insight" script
(involving adding to .gdbinit), but I want to see insight decoupled from
gdb proper, and this wouldn't help.  (Remember, we are a bastard project,
which is why we must keep the copyright assigned to Red Hat instead of the
FSF. It's not that we don't want the FSF to use Insight, but FSF insists
that tcl is evil.)

> What I've added will now check to see if gdb has been ran
> from a "bin" directory.  If not and TCL_LIBRARY isn't set,
> then it will set TCL_LIBRARY and then run a short embedded
> Tcl script to set the other *_LIBRARY before going on to
> start Insight.

I don't think this is unreasonable. Ugly maybe, but not unreasonable.

> You could also use this code to try and solve some of gdbtk's
> location independance problems.

Ugh. Configury is really the problem. I'm still in shock over last night's
little introduction to the complexities of gdb/insight configury.

> Is there any chance of major changes over that time?
> When are you planning to split gdb and insight in to
> seperate modules?

With every passing day, I make major changes, but I've got plenty of
battles in gdb-land to overcome before I can commit them. So don't sweat
it. I are a trained professional (TM). :-)

Keith