qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v1 5/5] .travis.yml: drop 32 bit systems from MAIN_SOFTMMU_TA


From: Thomas Huth
Subject: Re: [PATCH v1 5/5] .travis.yml: drop 32 bit systems from MAIN_SOFTMMU_TARGETS
Date: Tue, 19 Nov 2019 13:13:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0

On 13/11/2019 14.30, Thomas Huth wrote:
> On 13/11/2019 12.59, Alex Bennée wrote:
>> The older clangs are still struggling to build and run everything
>> withing the 50 minute timeout so lets lighten the load a bit more. We
>> still have coverage for GCC and hopefully no obscure 32 bit guest only
>> breakages slip through the cracks.
>>
>> Signed-off-by: Alex Bennée <address@hidden>
>> ---
>>  .travis.yml | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index b9a026c8eeb..c09b6a00143 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -79,7 +79,7 @@ env:
>>      - BASE_CONFIG="--disable-docs --disable-tools"
>>      - TEST_CMD="make check V=1"
>>      # This is broadly a list of "mainline" softmmu targets which have 
>> support across the major distros
>> -    - 
>> MAIN_SOFTMMU_TARGETS="aarch64-softmmu,arm-softmmu,i386-softmmu,mips-softmmu,mips64-softmmu,ppc64-softmmu,riscv64-softmmu,s390x-softmmu,x86_64-softmmu"
>> +    - 
>> MAIN_SOFTMMU_TARGETS="aarch64-softmmu,mips64-softmmu,ppc64-softmmu,riscv64-softmmu,s390x-softmmu,x86_64-softmmu"
>>      - CCACHE_SLOPPINESS="include_file_ctime,include_file_mtime"
>>      - CCACHE_MAXSIZE=1G
> 
> Reviewed-by: Thomas Huth <address@hidden>

On a second glance, we also have this entry with --target-list-exclude
in our test matrix:

    - env:
        - CONFIG="--disable-user
--target-list-exclude=${MAIN_SOFTMMU_TARGETS}"
        - CACHE_NAME="${TRAVIS_BRANCH}-linux-clang-default"
      compiler: clang

So while you've speed up one target, this one might get actually slower
instead. That's a little bit unfortunate. Is there maybe a better way to
tackle this?

 Thomas




reply via email to

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