[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/4] .travis.yml: reduce target list on core con
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [PATCH 2/4] .travis.yml: reduce target list on core configure tweaks |
Date: |
Mon, 18 Apr 2016 10:15:33 +0100 |
User-agent: |
mu4e 0.9.17; emacs 25.0.92.6 |
Peter Maydell <address@hidden> writes:
> On 15 April 2016 at 16:56, Alex Bennée <address@hidden> wrote:
>> A number of configure options only really affect the core code and any
>> arch specific stuff should be flushed out by other builds:
>>
>> - trace-backends, log build is all targets, others can be less
>> - --disable-build, ensuring disabling stuff doesn't break host
>> - co-routine, default already built with all, common API
>> - tcg interpreter is front end agnostic
>>
>> I've used the ./configure --target-list stem support to do all of one
>> arch type in each reduced build.
>>
>> Signed-off-by: Alex Bennée <address@hidden>
>> ---
>> .travis.yml | 18 +++++++++---------
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 50ac17f..d13bffc 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -45,10 +45,10 @@ env:
>> matrix:
>> - CONFIG=""
>> - CONFIG="--enable-debug --enable-debug-tcg --enable-trace-backends=log"
>> - - CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr
>> --disable-brlapi --disable-uuid --disable-libusb"
>> - - CONFIG="--enable-modules"
>> - - CONFIG="--with-coroutine=ucontext"
>> - - CONFIG="--with-coroutine=sigaltstack"
>> + - CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr
>> --disable-brlapi --disable-uuid --disable-libusb --target-list=86"
>> + - CONFIG="--enable-modules --target-list=86"
>
> I'm not really convinced by the wildcarding, and this seems like
> a good demonstration of why it's overbroad. "86" ??
Blame the x86 naming scheme for that. It works nicely for building all
arm, mips and ppc stuff quite nicely.
> The wildcarding gives you a configure command that will
> potentially change behaviour as we introduce new targets,
> too; that makes me a bit nervous.
Well it doesn't stop you using the full names but I take your point.
What about a different selection flag for selecting by backends?
>
> thanks
> -- PMM
--
Alex Bennée