Re: [PULL 1/1] Revert "configure: build ROMs with container-based cross compilers"

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Oct 12, 2022 at 08:46:35AM +0200, Paolo Bonzini wrote:
> Il mar 11 ott 2022, 21:29 Alex Bennée <alex.bennee@linaro.org> ha scritto:
> 
> > This reverts commit 730fe750fba63023e294ff0acf0f874369f1946f.
> >
> > Unconditionally building all the bios for all arches was a little too
> > far too fast.
> >
> 
> I would like to understand the issue better, because chances are that it is
> preexisting and applies to the TCG tests as well.
> 
> 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 ?

Note, my objection wasn't that the containers are broken - it did
eventually work. Rather the issues I see were

 * Downloading and building containers as part of 'make' made
   the build insanely slow due to my limited 4G network connectivity.
   It took over 1 GB of downloads, which doesn't sound like much
   for those with reliably high speed internet, but was absolutely
   awful for me as my 4G was very degraded at the time.

 * Downloading and building the containers printed lots of
   verbose progress information that destroyed the progress
   output from meson when doing a parallel build

 * The containers being built were not even used by the build
   process, as I filtered the target list to only x86 and thus
   had no cause to build s390 / ppc64 firmware.

 * When the container rebuild failed, restarting seemed to use
   the downloaded image, that was previously considered stale,
   instead of trying the fresh rebuild again.

IOW, I'd like to see

 - Explicit opt-in at configure time for use of container
   downloads during 'make'
 - Tailor downloads wrt the target list configured
 - Supress the verbose output to preserve meson progress
   readability
 - Handle failure during container builds correctly


The problem of data downloads during 'make' arguably applies to
submodules too, but few submodules are needed when the distro
has provided the required deps in packages, and so those submodules
left are small and their download isn't noticably slow / large data
volumes.

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 :|