|
From: | Jacob Bachmeyer |
Subject: | Provding a default compiler in default_target_compile |
Date: | Thu, 16 May 2019 22:46:54 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |