From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id CA5F4A0AC5 for ; Thu, 2 May 2019 15:57:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C44BB5F17; Thu, 2 May 2019 15:57:22 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 989C43253 for ; Thu, 2 May 2019 15:57:21 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3A72225A42; Thu, 2 May 2019 09:57:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 02 May 2019 09:57:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=/haoLWcWql1OCSF9Tjii5bNHH7ZjA+OrSKixSImv4f0=; b=KPsZ9KKJQpzt FVFVJYIp6pBQjyGjpmyCVmhdVWz7q9Iuh6fdr3pgU0kqz0vIjB0LMUlXz7oy5dTQ GWiKTWMm9eSfco0rE62KzX0h90mR0hxkqeMEvvMhw+4HyrAYUTj+rVn5d6EnAHY7 YO5DZHbbCC+UQKoBFa2ndAhdkisQJ2s= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=/haoLWcWql1OCSF9Tjii5bNHH7ZjA+OrSKixSImv4 f0=; b=QZA5Gs5NId49tnCSwKM4ACovN7647N3GSAkBSQZ3GAGAJtIS1MBLkko8R Lpv/wAJxqpG6048CAmNeHkK8hSKl1gbF1AbBCMgcVXlKrf9J8iPhBBOVa4Y0BWbn GGlI/PPHDJPxy2Qw4dOUwzRXqmRBLW90bTgbM8guEmXWp7QKcfiX8+nGSzAqN87g UTsYHQIm2XJXSgkeV8sMe5Xp1+jKFvZ0ksLkiiKXdH7QNjCaKOHnpQWE/8d+Wmdd 01iXdHQsCLjm1vBT9qJVQH88B5YGhQYSxI/jcovjSQ+LK3f7HdnGdtQWw2hDg2Xl dXwRAS5siIhsGQw9R+3n9IZ2H6jpg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieelgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D6D70103CA; Thu, 2 May 2019 09:57:19 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, bluca@debian.org Date: Thu, 02 May 2019 15:57:18 +0200 Message-ID: <3926136.XBKk6lCCy9@xps> In-Reply-To: <20190502132100.GB1980@bricha3-MOBL.ger.corp.intel.com> References: <20190423220644.54589-1-bruce.richardson@intel.com> <3343772.7GDin1kDO3@xps> <20190502132100.GB1980@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 4/6] devtools/test-meson-builds: add testing of pkg-config file 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" Message-ID: <20190502135718.l-vxg5uJf16uO-tLdxIIIDG_k1xie4M9aVIKABH3nGQ@z> 02/05/2019 15:21, Bruce Richardson: > On Thu, May 02, 2019 at 02:38:49PM +0200, Thomas Monjalon wrote: > > Hi, > > > > I will probably have a ton of comments about adding a new compilation tests, > > and I think it is a bit late for such an addition. > > However, all the fixes should go in 19.05. It would be more reasonnable to leave it for 19.08 and re-spin with fixes only. > > 26/04/2019 18:50, Bruce Richardson: > > > The pkg-config file generated as part of the build of DPDK should allow > > > applications to be built with an installed DPDK. We can test this as > > > part of the build by doing an install of DPDK to a temporary directory > > > within the build folder, and by then compiling up a few sample apps > > > using make working off that directory. > > > > > > Signed-off-by: Bruce Richardson > > > Acked-by: Luca Boccassi > > > --- > > > --- a/devtools/test-meson-builds.sh > > > +++ b/devtools/test-meson-builds.sh > > > +############## > > > +# Test installation of the x86-default target, to be used for checking > > > +# the sample apps build using the pkg-config file for cflags and libs > > > +############### > > > > I would prefer simpler comment formatting. > > It makes this test very special. > > Your comment implies that it is not :-) > Sure, I can reduce the highlighting. > > > > > > +build_path=build-x86-default > > > +DESTDIR=`pwd`/$build_path/install-root ; export DESTDIR > > > > export DESTDIR=... is not supported everywhere? > > No 100% sure, so left it like this just in case. Hmmm, i would prefer "export DESTDIR=" > > I prefer new shell substitution syntax $() instead of backquotes. > > > Sure, I agree it's more readable. > > > > +$ninja_cmd -C $build_path install > > > + > > > +pc_file=$(find $DESTDIR -name libdpdk.pc) > > > +PKG_CONFIG_PATH=$(dirname $pc_file) ; export PKG_CONFIG_PATH > > > + > > > +# rather than hacking our environment, just edit the .pc file prefix value > > > +sed -i -e "s|prefix=|prefix=$DESTDIR|" $pc_file > > > > What is the alternative? > > Cannot we configure meson with the right prefix? > > See previous discussion. > Short answer, yes we can, but the prefix does not apply to kernel modules > as they always install in /lib/modules folder. We could do better by providing this ability in our build system without hack. > > > +for example in helloworld l2fwd l3fwd skeleton timer; do > > > + echo "## Building $example" > > > + $MAKE -C $DESTDIR/usr/local/share/dpdk/examples/$example > > > +done > > > + > > > +echo "" > > > +echo "## $0: Completed OK" > > > > This last log is uncommon. > > > Yes, it is. However, due to parallelism, sometimes there is an error > message printed out that scrolls off-screen as the other build processes > come to a halt. I felt it worthwhile to add this at the end to ensure it > was clear whether things succeeded or not. If you prefer, I can change it > to a print on failure? Failures are caught by 'set -e'. Personnally I don't need such log because my shell prints me an error when $? is not 0, but I can understand the need. If you want to print $0, basename may render prettier.