* Jacob Bachmeyer <jcb62...@gmail.com> [2018-11-14 21:50:20 -0600]:
> This patch fixes the problem of the first "make check" after running
> configure complaining about being unable to find tool init files that I have
> previously described.
>
> ChangeLog entry
> --
> * runtest.exp (load_lib): Clean up whitespace.
> (load_tool_init): Search for tool init file instead of assuming
> exactly one location. Backwards compatibility is maintained.
This patch, combined with a recent change in GDB, means that GDB
testing no longer works. I can see what the problem is, but I was
hoping to get your guidance for what the best fix is.
I've explained more inline....
> --
> Patch attached due to whitespace issues.
>
>
> -- Jacob
>
> diff --git a/runtest.exp b/runtest.exp
> index 84e3e6b..5ced8ab 100644
> --- a/runtest.exp
> +++ b/runtest.exp
> @@ -596,7 +596,7 @@ proc load_lib { file } {
> set loaded_libs($file) ""
> set search_dirs [list ../lib $libdir $libdir/lib [file dirname [file
> dirname $srcdir]]/dejagnu/lib $srcdir/lib $execpath/lib . [file dirname [file
> dirname [file dirname $srcdir]]]/dejagnu/lib]
> if {[info exists libdirs]} {
> - lappend search_dirs $libdirs
> + lappend search_dirs $libdirs
> }
> if { [search_and_load_file "library file" $file $search_dirs ] == 0 } {
> send_error "ERROR: Couldn't find library file $file.\n"
> @@ -929,25 +929,21 @@ proc load_tool_init { file } {
> global srcdir
> global loaded_libs
>
> - if {[info exists loaded_libs($file)]} {
> + if {[info exists loaded_libs(tool/$file)]} {
> return
> }
>
> - set loaded_libs($file) ""
> -
> - verbose "Looking for tool init file $srcdir/lib/$file"
> + set loaded_libs(tool/$file) ""
This change is the one that causes problems. Previously the call to
'load_tool_init' resulted in the tool init file being recorded in
'loaded_libs' just like any other library file - using just the name
of the file, so for GDB this was 'gdb.exp'.
After this patch the tool init file is recorded as 'tool/gdb.exp'.
GDB (probably wrongly) includes, from its target init files (for
example gdb/testsuite/config/unix.exp), the tool init file using
'load_lib gdb.exp'.
The problem is that gdb.exp now ends up getting included twice, first
time it is included and recorded as 'tool/gdb.exp' and the second time
as just 'gdb.exp'. A recent change means that this file can _only_ be
parsed once (a use of rename is the blocker).
Prior to this patch the second attempt to include 'gdb.exp' would be
ignored as 'gdb.exp' was already in loaded_libs.
The obvious fix is probably just, remove the 'load_lib gdb.exp' calls
from the GDB testsuite, however, I wanted to ask a few questions
first:
It's not clear from this patch why this change was necessary, could we
revert to the old behaviour?
There's many calls to 'search_and_load_file' in dejagnu (the core of
things like load_lib and load_tool_init), but only some of them are
guarded with a check of loaded_libs. Would there be an advantage of
moving the loaded_libs check into 'search_and_load_file', and placing
the absolute path to the file being loaded into loaded_libs?
Thanks for your time,
Andrew
>
> - if {[file exists [file join ${srcdir} lib $file]]} {
> - verbose "Loading library file ${srcdir}/lib/$file"
> - if { [catch "uplevel #0 source ${srcdir}/lib/$file"] == 1 } {
> - send_error "ERROR: tcl error sourcing library file
> ${srcdir}/lib/$file.\n"
> - global errorInfo
> - if {[info exists errorInfo]} {
> - send_error "$errorInfo\n"
> - }
> - exit 1
> - }
> + if { [lindex [file split $srcdir] end] != "testsuite" } {
> + lappend searchpath [file join $srcdir testsuite lib tool]
> + lappend searchpath [file join $srcdir testsuite lib]
> } else {
> + lappend searchpath [file join $srcdir lib tool]
> + }
> + lappend searchpath [file join $srcdir lib]
> +
> + if { ![search_and_load_file "tool init file" [list $file] $searchpath] }
> {
> warning "Couldn't find tool init file"
> }
> }
> _______________________________________________
> DejaGnu mailing list
> DejaGnu@gnu.org
> https://lists.gnu.org/mailman/listinfo/dejagnu
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
