This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[RFC] get_compiler_info should cache it's results
- From: Paul Gilliam <pgilliam at us dot ibm dot com>
- To: gdb-patches at sources dot redhat dot com
- Cc: Daniel Jacobowitz <drow at false dot org>
- Date: Thu, 10 Mar 2005 15:57:05 -0800
- Subject: [RFC] get_compiler_info should cache it's results
- Reply-to: pgilliam at us dot ibm dot com
Hi all,
We are trying to use IBM's xlc compiler with the testsuite and have found
severial places that break because of differences if flags. For example, gcc
uses '-shared' but xlc uses '-qmkshrobj' in order to indicate that a shared
object is to be produced.
I have written a tcl proc that will make this easyer. It's kind of like a
special front-end to 'test_compiler_info', which depends on
'get_compiler_info' being run first.
I would like to run get_compiler_info from within this new proc, but that
could result in running it multiple times in a given test.
For this reason, I would like 'get_compiler_info' to cache its resluts by
simply starting the proc with something like:
if [info exists compiler_info] {return 0}
Does anyone see any problems with this?
-=# Paul #=-
Here is the new proc (so far ;-):
proc compile_flags { arg1 {arg2 ""} } {
if {"$arg2" == ""} then {
set list $arg1
} else {
upvar $arg1 lvar
set list $arg2
}
if ![info exists lvar] { set lvar {} }
get_compiler_info not-used
foreach {pat flist} $list {
if {$pat == {default}} {
return [eval $flist]
} elseif {[test_compiler_info $pat]} {
foreach flag $flist {
set lvar "$lvar additional_flags=$flag"
}
set lvar [string trim $lvar]
return $lvar
}
}
return {}
}
I just realized that this ignores the second argument to 'get_compiler_info'
which defaults to 'c' but could be 'c++' (and someday may be ada, fortran,
pascal ...) I guess my 'compile_flags' would need a 'language' argument to
pass to 'get_compiler_info', which could cache it's results with an array
indexed by 'language'.