On Mon, Dec 07, 2020 at 07:12:32PM +0100, Thomas Monjalon wrote: > 07/12/2020 18:47, Bruce Richardson: > > On Mon, Dec 07, 2020 at 06:33:19PM +0100, Thomas Monjalon wrote: > > > When testing compilation and checking ABI compatibility, > > > there is no real need of static binaries eating disks. > > > The static linkage of applications are tested with GCC and Clang, > > > plus some examples are statically linked. > > > The after-installation build test is limited to "helloworld" example. > > > Note the meson static build test was already limited to "l3fwd" example. > > > > > > The ABI compatibility is checked on shared libraries, so no need > > > running this test a second time on builds intended for static linking. > > > However, limiting ABI check to "shared builds" means all test cases > > > must have a "shared build" occurence. > > > As a consequence the 32-bit build test is switched to shared linking. > > > > > > Signed-off-by: Thomas Monjalon <tho...@monjalon.net> > > > --- > > > devtools/test-meson-builds.sh | 8 ++++++-- > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > I think this might be better as two patches - one for the ABI check changes > > and a second for the example build changes with installed DPDK. > > Yes could be 2 patches. > > > > > for example in $examples; do > > > echo "## Building $example" > > > + [ $example = helloworld ] && static=static || static= # save > > > disk space > > > $MAKE -C $DESTDIR/usr/local/share/dpdk/examples/$example \ > > > - clean shared static >&$veryverbose > > > + clean shared $static >&$veryverbose > > > done > > > fi > > > > Just wonder are we likely to miss things with this change? Would changing > > the order to do a clean at the end to free back up the disk space not > > achieve much the same result while still saving disk space? > > Not building static flavour of most examples is also faster. > Ideally we should not rebuild an example if the libs did not change. > > To the question "will we miss something", the difference between static > and shared examples is just the pkg-config call in the Makefile. > I think the risk is small. > Yes, for the majority of the apps that is the case. However, the only concern I have is for a number of the apps which link directly against a driver or two. Looking at vm_power_manager example, which links against 3 drivers, I see that the extra flags are only added for shared builds so we should be ok for that one anyway.
Therefore ok with this change exactly as you suggest. /Bruce
