dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Provding a default compiler in default_target_compile


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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]