This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Parallel testing of multilibs
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: Parallel testing of multilibs
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 10 Jan 2001 10:14:48 +0000
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> On Jan 9, 2001, Richard Henderson <rth@redhat.com> wrote:
>
> > On Tue, Jan 09, 2001 at 05:04:26PM -0200, Alexandre Oliva wrote:
> >> Or did you just mean to do brace expansion by hand?
>
> > Yes. Via iterative parsing of --print-multi-lib, as is
> > (was? did they all get moved to mklibgcc.in?) done elsewhere
> > in the makefile.
>
> Oh! I was thinking of multilibs, as set in site.exp.
> -print-multi-lib is far easier, indeed :-)
I really, really, like this idea given that I have 9 multi-lib variants to
test on a cross build. However, this is still too much to run in a single
night, given that I only have access to a 2-cpu machine. With this
feature, will I still be able to control which variants get tested in a
single "make check"? With the current system I have the following in my
site.exp to control this:
{ "arm*-*-elf*" } {
case [timestamp -format "%A"] in {
{ "Monday" } {
set target_list { "arm-sim/-mhard-float" }
}
{ "Tuesday" } {
set target_list { "arm-sim/-mbig-endian/-msoft-float" }
}
{ "Wednesday" } {
set target_list { "arm-sim/-mbig-endian/-mcpu=arm7tdmi" }
...
It would be nice to run two or three combinations in a single night, but I
really don't want to have to run all nine (or more -- if I can practically
test more variants, it might be reasonable to build more).
R.