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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).