qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/5] .travis.yml: Build and install EDK2 roms


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH 5/5] .travis.yml: Build and install EDK2 roms
Date: Tue, 12 Mar 2019 17:29:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 03/11/19 01:30, Philippe Mathieu-Daudé wrote:
> Add a job to build and install the EDK2 platform firmware binaries.
> 
> This job is only triggered if the last commit matches the EDK2
> name (case insensitive), or when tag are created (such releases
> or release candidates).
> 
> Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
> ---
>  .travis.yml | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index e942175dd3..628cc52c99 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -258,3 +258,24 @@ matrix:
>      - env:
>          - CONFIG="--disable-system"
>          - TEST_CMD="make -j3 check-tcg V=1"
> +
> +
> +    # EDK2 roms builds
> +    - if: tag IS present OR commit_message =~ /(edk2|EDK2)/
> +      env:
> +        - CONFIG="--disable-system --disable-user --prefix=$PWD/dist"
> +        - EDK2_BUILD_OPTIONS="--quiet --silent"
> +      script:
> +        - git submodule update --init roms/edk2
> +        - make -j3
> +        - make -C roms efi -j2
> +        - make install
> +      addons:
> +        apt:
> +          packages:
> +            - dos2unix
> +            - gcc-aarch64-linux-gnu
> +            - gcc-arm-linux-gnueabihf
> +            - iasl
> +            - nasm
> +            - uuid-dev
> 

Regardless of what problem we're trying to address with "--quiet
--silent", those options are wrong. You certainly want detailed build
logs for the case a CI job fails (at build time or at runtime).

The reason why I only include DEBUG firmware builds in the edk2 bundling
series is similar -- RELEASE builds lack DEBUG messages and ASSERT()s,
and as such they are 100% unsupportable in my book. Bugs in software are
the norm, not the exception, so we should allow (even force) the user
(and remote systems) to provide as much information as they can.

Thanks
Laszlo



reply via email to

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