One of the minor bugs on my local TODO list for some time now has been
cleaning up whatever it is that produces lots of messages ending in
"xgcc" at verbose 2+. I had quickly found that those messages are from
the find_gcc procedure and that it is being called at {set_board_info
compiler "[find_gcc]"} in baseboards/unix.exp. At the time, I did not
understand enough to propose a solution and just left it in my TODO list.
I now have a solution: establish a default compiler in
default_target_compile, by using [find_gcc] if the compiler_type is
still the default "c" just before complaining about "No compiler to
compile with" and make the "compiler" key in board_info optional. I am
asking about this before making a patch, since the patch will involve
removing {set_board_info compiler "[find_gcc]"} from all of the
baseboard files that use it, except for multi-sim, which is the only
file that seems to actually rely on it -- in the others, it is just
boilerplate. (And I currently believe that if you are running with a
multi-sim target, you probably *do* want to compile test cases, so you
really do need the compiler.) A quick grep suggests that nothing else
relies on the board_info compiler option:
lib/libgloss.exp:get_multilibs will use it as an override, but falls
back to [find_gcc] if it is not defined.
Setting the board_info compiler value to "[find_gcc]" would still work,
of course, (and leaving it in multi-sim will help to ensure this) so
existing out-of-tree board files would not break as a result of this
change. In effect, I propose a default value for [board_info $whatever
compiler] that is only evaluated if the testsuite actually wants to use
a compiler. This change would both reduce "noise" at higher verbose
levels and reduce the boilerplate needed for a baseboard file.
Any comments on the idea before I write a patch? If we use [find_gcc]
in default_target_compile, should we memoize the result using
set_board_info? Or is find_gcc fast enough that evaluating it
repeatedly would not be a problem?
-- Jacob
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
