On Mon, Mar 16, 2020 at 10:13:23AM -0400, Aaron Conole wrote: > David Marchand <david.march...@redhat.com> writes: > > > On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <acon...@redhat.com> wrote: > >> > >> Aaron Conole <acon...@redhat.com> writes: > >> > >> > Ruifeng Wang <ruifeng.w...@arm.com> writes: > >> > > >> >> For environments (such as containers) where hugetlbfs are not available, > >> >> some unit tests can be run with 'no-huge' option. > >> >> > >> >> fast-tests suites is generated dynamically according to hugetlbfs > >> >> availability in building environment. This allows unit test to run > >> >> in different environments using the same suite name. > >> >> > >> >> Several test cases are fixed to be able to run in no-huge mode. > >> > > >> > This looks great! Thanks, Ruifeng. > >> > > >> > I'm going to ack it once I see it run under the robot :) > >> > >> Just looking through the robot's run, it seems that on the statically > >> linked Arm64 build, the disk quota is getting exceeded. Do we need to > >> request some more disk quota for this somehow? Is the build getting too > >> large? > > I think as a general rule we need to limit the number of static builds we do, and possibly skip building all the examples for the static builds. Given we have almost 50 examples, that's a lot of linking of libraries into binaries. For meson builds, perhaps we only pass -Dexamples=all for the shared builds, and maybe do -Dexamples=l3fwd or similar for the static ones. One or two examplse to check that the linking works with examples should be enough if we test the build of the examples themselves in the shared build jobs.
Thoughts? /Bruce
