From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Hajnoczi, Stefan" <stefanha@redhat.com>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>
Subject: Re: [PULL 1/1] Revert "configure: build ROMs with container-based cross compilers"
Date: Wed, 12 Oct 2022 10:08:37 +0100 [thread overview]
Message-ID: <Y0aEFUOU0DCWgvcL@redhat.com> (raw)
In-Reply-To: <bd325ff3-831e-ca4d-4ada-e2650a0a908b@redhat.com>
On Wed, Oct 12, 2022 at 10:59:54AM +0200, Paolo Bonzini wrote:
> On 10/12/22 10:14, Daniel P. Berrangé wrote:
> > > Daniel, does building the TCG tests work for you? If not, I think we should
> > > just disable containers by default.
> >
> > I've never (knowingly) tried running TCG tests. IIUC, they are strictly
> > an opt-in test needing explicit 'make check-tcg', so any container usage
> > wouldn't be encountered by most contributors ?
>
> Yeah, that is true. But the problems below affect all container usage
> rather than just firmware builds, so they should be fixed there. configure
> is able to only run 'make check-tcg' for targets which have a compiler
> installed.
>
> > IOW, I'd like to see
> >
> > - Explicit opt-in at configure time for use of container
> > downloads during 'make'
>
> This is what I'm proposing, and extending to all targets.
Ok, makes sense.
> > - Tailor downloads wrt the target list configured
>
> This is already done.
Where's the patch for that, I hadn't noticed it being posted yet ?
> > - Suppress the verbose output to preserve meson progress
> > readability
>
> That's in general a tradeoff with long-running tasks. It's difficult to say
> which is better, for example "make check" also has a verbose output.
If 'make' was running with V=1, then also letting docker download be
verbose makes sense.
The plain 'make' though is intentionally quite terse, just giving a
list of files meson compiles. Right now, the output ends up looking
like this:
[2715/2945] Compiling C object tests/unit/test-xbzrle.p/test-xbzrle.c.o
[2716/2945] Linking target tests/unit/test-authz-pam
Copying blob bd159e379b3b skipped: already exists
Copying blob fc8d65e34cd5 [>-------------------------------------] 9.3MiB / 360.2MiB
Copying blob 13224e2971af [--------------------------------------] 1.1MiB / 366.5MiB
[2720/2945] Linking target tests/unit/test-io-channel-tls
Copying blob bd159e379b3b skipped: already exists
Copying blob fc8d65e34cd5 [>-------------------------------------] 9.4MiB / 360.2MiB
Copying blob 13224e2971af [--------------------------------------] 1.2MiB / 366.5MiB
[2724/2945] Linking target tests/unit/test-io-task
[2725/2945] Compiling C object tests/unit/test-util-sockets.p/test-util-sockets.c.o
[2726/2945] Compiling C object tests/unit/test-util-sockets.p/socket-helpers.c.o
[2727/2945] Linking target tests/unit/test-xbzrle
[2728/2945] Compiling C object tests/unit/test-base64.p/test-base64.c.o
[2729/2945] Linking target tests/unit/test-timed-average
[2730/2945] Compiling C object tests/unit/test-bufferiszero.p/test-bufferiszero.c.o
Copying blob bd159e379b3b skipped: already exists
Copying blob 2a205c8a1d36 [>-------------------------------------] 4.4MiB / 257.2MiB
Copying blob bd159e379b3b skipped: already exists
Copying blob fc8d65e34cd5 [>-------------------------------------] 9.5MiB / 360.2MiB
Copying blob 13224e2971af [--------------------------------------] 1.3MiB / 366.5MiB
[2736/2945] Compiling C object tests/unit/test-yank.p/test-yank.c.o
[2737/2945] Compiling C object tests/unit/test-util-filemonitor.p/test-util-filemonitor.c.o
Copying blob bd159e379b3b skipped: already exists
Copying blob fc8d65e34cd5 [>-------------------------------------] 9.6MiB / 360.2MiB
Copying blob 13224e2971af [--------------------------------------] 1.3MiB / 366.5MiB
which I feel is quite unplesant, especially when you then get
multiple parallel docker downloads concurrently refreshing the
screen and overwriting each others' output.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-10-12 9:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 19:28 [PULL 0/1] testing: revert pc-bios build patch Alex Bennée
2022-10-11 19:28 ` [PULL 1/1] Revert "configure: build ROMs with container-based cross compilers" Alex Bennée
2022-10-12 6:46 ` Paolo Bonzini
2022-10-12 8:14 ` Daniel P. Berrangé
2022-10-12 8:59 ` Paolo Bonzini
2022-10-12 9:08 ` Daniel P. Berrangé [this message]
2022-10-12 14:32 ` Paolo Bonzini
2022-10-12 11:04 ` Daniel Henrique Barboza
2022-10-12 12:13 ` Alex Bennée
2022-10-12 13:24 ` Daniel Henrique Barboza
2022-10-13 15:39 ` Alex Bennée
2022-10-13 17:07 ` Daniel Henrique Barboza
2022-10-11 19:33 ` [PULL 0/1] testing: revert pc-bios build patch Stefan Hajnoczi
2022-10-12 14:09 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0aEFUOU0DCWgvcL@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=danielhb413@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.