From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 011F5A09E5; Tue, 8 Dec 2020 10:33:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3681BC908; Tue, 8 Dec 2020 10:33:17 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 0BDABC8FA for ; Tue, 8 Dec 2020 10:33:15 +0100 (CET) IronPort-SDR: cj7OYBK+o0VIaSjyvJn2TIrsNy6HMl9dXDbapuOWclKh7a4hmOlyiWUW/8741rv66V90dFF/ki FUtnDJFs6lQg== X-IronPort-AV: E=McAfee;i="6000,8403,9828"; a="170352703" X-IronPort-AV: E=Sophos;i="5.78,402,1599548400"; d="scan'208";a="170352703" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Dec 2020 01:33:10 -0800 IronPort-SDR: 8QOf84B7jKadd6k5zjvmBnupD1u7PvA4O42LoHyvZ+Q2yLbEt7PNXWASUfWVQbDPyx/OBFFpLu 17Fa7wJagKJQ== X-IronPort-AV: E=Sophos;i="5.78,402,1599548400"; d="scan'208";a="437318988" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.87.148]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 08 Dec 2020 01:33:09 -0800 Date: Tue, 8 Dec 2020 09:33:03 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org, david.marchand@redhat.com Message-ID: <20201208091530.GA1075@bricha3-MOBL.ger.corp.intel.com> References: <20201207173319.1397740-1-thomas@monjalon.net> <20201207174754.GA24@bricha3-MOBL.ger.corp.intel.com> <4516256.vyG4RrSlNk@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4516256.vyG4RrSlNk@thomas> Subject: Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > --- > > > 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