* gdb.gdbtk tests
@ 2000-03-23 11:53 Jimmy Guo
2000-03-23 14:56 ` Andrew Cagney
2000-04-01 0:00 ` Jimmy Guo
0 siblings, 2 replies; 8+ messages in thread
From: Jimmy Guo @ 2000-03-23 11:53 UTC (permalink / raw)
To: gdb
These tests apparently require top level tk/, tix/, itcl/, and libgui/
(the Cygnus GUI) components be present in the source tree (per
gdb/testsuite/lib/gdb.exp (gdbtk_start)). Will these components be part
of public tree any time soon?
Besides, it's better to have a sanity check routine testing all
dependencies before even trying gdb_compile, like the skip_hp_tests one.
Some codes like below will be better:
set path [file join <whatever path>]
if ![file isdirectory $path] {
perror <error message>
return 1 (or exit 1)
}
- Jimmy Guo, guo@cup.hp.com
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: gdb.gdbtk tests
2000-03-23 11:53 gdb.gdbtk tests Jimmy Guo
@ 2000-03-23 14:56 ` Andrew Cagney
2000-03-23 15:02 ` Jimmy Guo
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` Jimmy Guo
1 sibling, 2 replies; 8+ messages in thread
From: Andrew Cagney @ 2000-03-23 14:56 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb, Insight (GDB GUI)
Jimmy Guo wrote:
>
> These tests apparently require top level tk/, tix/, itcl/, and libgui/
> (the Cygnus GUI) components be present in the source tree (per
> gdb/testsuite/lib/gdb.exp (gdbtk_start)). Will these components be part
> of public tree any time soon?
They are already available. Either download the insight+dejagnu
snapshot or checkout the module ``insight''.
> Besides, it's better to have a sanity check routine testing all
> dependencies before even trying gdb_compile, like the skip_hp_tests one.
>
> Some codes like below will be better:
>
> set path [file join <whatever path>]
> if ![file isdirectory $path] {
> perror <error message>
> return 1 (or exit 1)
> }
The ``GDB'' module doesn't include the gdb.gdbtk testsuites. However,
given that it's pretty easy to end up with that directory, a more robust
test would be better.
The MI testsuite checks that the GDB binary.
enjoy,
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: gdb.gdbtk tests
2000-03-23 14:56 ` Andrew Cagney
@ 2000-03-23 15:02 ` Jimmy Guo
2000-03-23 16:50 ` Andrew Cagney
2000-04-01 0:00 ` Jimmy Guo
2000-04-01 0:00 ` Andrew Cagney
1 sibling, 2 replies; 8+ messages in thread
From: Jimmy Guo @ 2000-03-23 15:02 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb, Insight (GDB GUI)
>They are already available. Either download the insight+dejagnu
>snapshot or checkout the module ``insight''.
Oh, I only extract gdb + dejagnu.
>The ``GDB'' module doesn't include the gdb.gdbtk testsuites. However,
>given that it's pretty easy to end up with that directory, a more robust
>test would be better.
I don't know if there's any easy way to maintain the modules aliases to
separate out the gdb.gdbtk test suite from mainline gdb tree. As of
3/21 that's not the case (or I wouldn't see the test suite). Keeping it
in the tree would be fine provided that a better bypass than the current
(let TCL complain about 'cd' failure and dump call trace). For now,
locally, I'm adding gdb.gdbtk to the skip list in site.exp.
- Jimmy
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb.gdbtk tests
2000-03-23 15:02 ` Jimmy Guo
@ 2000-03-23 16:50 ` Andrew Cagney
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` Jimmy Guo
1 sibling, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2000-03-23 16:50 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb, Insight (GDB GUI)
Jimmy Guo wrote:
>
> >They are already available. Either download the insight+dejagnu
> >snapshot or checkout the module ``insight''.
>
> Oh, I only extract gdb + dejagnu.
>
> >The ``GDB'' module doesn't include the gdb.gdbtk testsuites. However,
> >given that it's pretty easy to end up with that directory, a more robust
> >test would be better.
>
> I don't know if there's any easy way to maintain the modules aliases to
> separate out the gdb.gdbtk test suite from mainline gdb tree. As of
> 3/21 that's not the case (or I wouldn't see the test suite). Keeping it
> in the tree would be fine provided that a better bypass than the current
> (let TCL complain about 'cd' failure and dump call trace). For now,
> locally, I'm adding gdb.gdbtk to the skip list in site.exp.
At a technical level, yes it is possible. The modules file and the
repository can be structured such that ``cvs co'' mix-n-matches a
collection of directories into a specific local structure. It was
considered when the GDB and binutils repositories were merged but
discarded as unnecessary at the time.
The relevant tests should be fixed.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb.gdbtk tests
2000-03-23 16:50 ` Andrew Cagney
@ 2000-04-01 0:00 ` Andrew Cagney
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb, Insight (GDB GUI)
Jimmy Guo wrote:
>
> >They are already available. Either download the insight+dejagnu
> >snapshot or checkout the module ``insight''.
>
> Oh, I only extract gdb + dejagnu.
>
> >The ``GDB'' module doesn't include the gdb.gdbtk testsuites. However,
> >given that it's pretty easy to end up with that directory, a more robust
> >test would be better.
>
> I don't know if there's any easy way to maintain the modules aliases to
> separate out the gdb.gdbtk test suite from mainline gdb tree. As of
> 3/21 that's not the case (or I wouldn't see the test suite). Keeping it
> in the tree would be fine provided that a better bypass than the current
> (let TCL complain about 'cd' failure and dump call trace). For now,
> locally, I'm adding gdb.gdbtk to the skip list in site.exp.
At a technical level, yes it is possible. The modules file and the
repository can be structured such that ``cvs co'' mix-n-matches a
collection of directories into a specific local structure. It was
considered when the GDB and binutils repositories were merged but
discarded as unnecessary at the time.
The relevant tests should be fixed.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb.gdbtk tests
2000-03-23 15:02 ` Jimmy Guo
2000-03-23 16:50 ` Andrew Cagney
@ 2000-04-01 0:00 ` Jimmy Guo
1 sibling, 0 replies; 8+ messages in thread
From: Jimmy Guo @ 2000-04-01 0:00 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb, Insight (GDB GUI)
>They are already available. Either download the insight+dejagnu
>snapshot or checkout the module ``insight''.
Oh, I only extract gdb + dejagnu.
>The ``GDB'' module doesn't include the gdb.gdbtk testsuites. However,
>given that it's pretty easy to end up with that directory, a more robust
>test would be better.
I don't know if there's any easy way to maintain the modules aliases to
separate out the gdb.gdbtk test suite from mainline gdb tree. As of
3/21 that's not the case (or I wouldn't see the test suite). Keeping it
in the tree would be fine provided that a better bypass than the current
(let TCL complain about 'cd' failure and dump call trace). For now,
locally, I'm adding gdb.gdbtk to the skip list in site.exp.
- Jimmy
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb.gdbtk tests
2000-03-23 14:56 ` Andrew Cagney
2000-03-23 15:02 ` Jimmy Guo
@ 2000-04-01 0:00 ` Andrew Cagney
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb, Insight (GDB GUI)
Jimmy Guo wrote:
>
> These tests apparently require top level tk/, tix/, itcl/, and libgui/
> (the Cygnus GUI) components be present in the source tree (per
> gdb/testsuite/lib/gdb.exp (gdbtk_start)). Will these components be part
> of public tree any time soon?
They are already available. Either download the insight+dejagnu
snapshot or checkout the module ``insight''.
> Besides, it's better to have a sanity check routine testing all
> dependencies before even trying gdb_compile, like the skip_hp_tests one.
>
> Some codes like below will be better:
>
> set path [file join <whatever path>]
> if ![file isdirectory $path] {
> perror <error message>
> return 1 (or exit 1)
> }
The ``GDB'' module doesn't include the gdb.gdbtk testsuites. However,
given that it's pretty easy to end up with that directory, a more robust
test would be better.
The MI testsuite checks that the GDB binary.
enjoy,
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* gdb.gdbtk tests
2000-03-23 11:53 gdb.gdbtk tests Jimmy Guo
2000-03-23 14:56 ` Andrew Cagney
@ 2000-04-01 0:00 ` Jimmy Guo
1 sibling, 0 replies; 8+ messages in thread
From: Jimmy Guo @ 2000-04-01 0:00 UTC (permalink / raw)
To: gdb
These tests apparently require top level tk/, tix/, itcl/, and libgui/
(the Cygnus GUI) components be present in the source tree (per
gdb/testsuite/lib/gdb.exp (gdbtk_start)). Will these components be part
of public tree any time soon?
Besides, it's better to have a sanity check routine testing all
dependencies before even trying gdb_compile, like the skip_hp_tests one.
Some codes like below will be better:
set path [file join <whatever path>]
if ![file isdirectory $path] {
perror <error message>
return 1 (or exit 1)
}
- Jimmy Guo, guo@cup.hp.com
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-23 11:53 gdb.gdbtk tests Jimmy Guo
2000-03-23 14:56 ` Andrew Cagney
2000-03-23 15:02 ` Jimmy Guo
2000-03-23 16:50 ` Andrew Cagney
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` Jimmy Guo
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` Jimmy Guo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).