Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries

[Thomas Monjalon <thomas@monjalon.net>]

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 <thomas@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.