Suppose one has a full source tree layout that is not the usual
Cygnus layout (where everybody is a sibling).
i.e. instead of
$top/gcc
$top/gas
$top/newlib
$top/[etc]
one has
$top/gcc/gcc [plus all the other subdirs in a gcc release]
$top/binutils/gas [plus all the other subdirs in a binutils release]
$top/newlib/newlib [plus all the other subdirs in a newlib release]
ie. each of the gcc,binutils,newlib releases are unpacked
as siblings, but the underlying components live in their separate
release source trees.
Things might even be unpacked as
$top/gcc-4.0.0/gcc
$top/binutils-2.16/gas
$top/newlib-1.12/newlib
[or whatever release the user happens to be using]
dejagnu has builtin support to work in the Cygnus-style layout.
e.g. lib/libgloss.exp:newlib_include_flags will properly compute the
newlib flags for a Cygnus-style-everyone-is-a-sibling tree.
But the second layout above (where each individual release is untarred
separately) isn't currently supported by newlib_include_flags.
I would like to find an acceptable way to support the style
where each release is unpacked separately. Do people think that's
possible?
newlib_include_flags uses lookfor_file which will search up the
directory heirarchy a bit but that doesn't quite help.
runtest.exp:lookfor_file:
foreach x ".. ../.. ../../.. ../../../.." {
It will look for ../newlib/libc but not ../newlib/newlib/libc.
Obviously I wouldn't change lookfor_file to implement this,
one wouldn't want to encode knowledge of the newlib
source tree layout in lookfor_file. But the caller of lookfor_file,
e.g. newlib_include7_flags, knows the layout of the release so it can
know what to look for.
Does adding support to newlib_include_flags (and the other procs
in libgloss.exp) to look for newlib/newlib/libc seem reasonable (*1)?
(*1): One would also need to decide if/how to deal with looking for
newlib-<release#>/newlib/libc.
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
http://lists.gnu.org/mailman/listinfo/dejagnu
