newlib_include_flags/newlib_link_flags [libgloss,etc. too]

[Doug Evans]

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.