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

[Bruce Richardson <bruce.richardson@intel.com>]

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