From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 8E8C71B114 for ; Thu, 2 May 2019 17:30:44 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2019 08:30:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,422,1549958400"; d="scan'208";a="136257431" Received: from dshirizl-mobl1.ger.corp.intel.com ([10.252.11.108]) by orsmga007.jf.intel.com with SMTP; 02 May 2019 08:30:41 -0700 Received: by (sSMTP sendmail emulation); Thu, 02 May 2019 16:30:40 +0100 Date: Thu, 2 May 2019 16:30:40 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: Luca Boccassi , dev@dpdk.org Message-ID: <20190502153040.GA322@bricha3-MOBL.ger.corp.intel.com> References: <20190423220644.54589-1-bruce.richardson@intel.com> <20190502131738.GA1980@bricha3-MOBL.ger.corp.intel.com> <33cd0a15409b4af2d93bcfba804566ea09e7c0cb.camel@debian.org> <5943797.eKmBmZ8x9O@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5943797.eKmBmZ8x9O@xps> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 3/4] 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: , X-List-Received-Date: Thu, 02 May 2019 15:30:45 -0000 On Thu, May 02, 2019 at 05:11:30PM +0200, Thomas Monjalon wrote: > 02/05/2019 16:08, Luca Boccassi: > > On Thu, 2019-05-02 at 14:17 +0100, Bruce Richardson wrote: > > > On Thu, May 02, 2019 at 03:11:10PM +0200, Thomas Monjalon wrote: > > > > 26/04/2019 16:56, Bruce Richardson: > > > > > On Wed, Apr 24, 2019 at 02:37:58PM +0100, Luca Boccassi wrote: > > > > > > On Wed, 2019-04-24 at 13:31 +0100, Bruce Richardson wrote: > > > > > > > On Wed, Apr 24, 2019 at 12:02:24PM +0100, Luca Boccassi > > > > > > > wrote: > > > > > > > > On Wed, 2019-04-24 at 11:41 +0100, Bruce Richardson wrote: > > > > > > > > > On Wed, Apr 24, 2019 at 10:22:04AM +0100, Luca Boccassi > > > > > > > > > wrote: > > > > > > > > > > On Tue, 2019-04-23 at 23:06 +0100, Bruce Richardson > > > > > > > > > > wrote: > > > > > > > > > > > +# > > > > > > > > > > > rather > > > > > > > > > > > than hacking our environment, just edit the .pc file > > > > > > > > > > > prefix > > > > > > > > > > > value > > > > > > > > > > > +sed > > > > > > > > > > > -i "s|prefix=|prefix=$DESTDIR|" > > > > > > > > > > > $PKG_CONFIG_PATH/libdpdk.pc > > > > > > > > > > > > > > > > > > > > What about just using meson's prefix option instead? > > > > > > > > > > Which is > > > > > > > > > > how > > > > > > > > > > it > > > > > > > > > > would be used in a real use case > > > > > > > > > > > > > > > > > > I don't think that would fully work, as my understanding > > > > > > > > > is that > > > > > > > > > the > > > > > > > > > prefix > > > > > > > > > option would apply only to the /usr/local parts, but not > > > > > > > > > to the > > > > > > > > > kernel > > > > > > > > > modules which would still try and install in /lib/. > > > > > > > > > > > > > > > > What about doing a meson configure -Denable_kmods=false > > > > > > > > before the > > > > > > > > ninja install? The modules are not needed for that test > > > > > > > > anyway, > > > > > > > > right? > > > > > > > > Alternatively, the kernel src dir could be symlinked in the > > > > > > > > build > > > > > > > > path, > > > > > > > > and the kernel_dir option could be used > > > > > > > > > > > > > > > > I'm just worried that the test should be as "realistic" as > > > > > > > > possible, to > > > > > > > > avoid missing something > > > > > > > > > > > > > > Yes, I did think of that too, but it does mean doing another > > > > > > > configuration > > > > > > > run in meson, and possibly a rebuild too if the > > > > > > > rte_build_config.h > > > > > > > file > > > > > > > changes. Therefore I decided to use DESTDIR for the sake of > > > > > > > speed > > > > > > > here. I > > > > > > > assumed there would be a pkg-config variable to adjust the > > > > > > > output > > > > > > > paths > > > > > > > based on a sysroot, but couldn't find a suitable one. > > > > > > > > [...] > > > > > > There actually is a pkg-config binary option, I just tried and > > > > > > it works > > > > > > (it seems to be disabled by default on Debian and derivatives): > > > > > > -- > > > > > > define-prefix > > > > > > > > > > > > > > > > Any cmdline options to pkg-config don't solve the problem here as > > > > > it means > > > > > that the makefiles for any app need to be modified to use all > > > > > those. > > > > > > > > It looks to be a good solution. > > > > Being able to update the DPDK install directory when building > > > > an application should be a mandatory requirement. > > > > I suggest to wrap the call to pkg-config so we can have this > > > > ability. > > > > > > > > > > I would have expected that this issue has already been solved for > > > packagers. I was surprised that I couldn't find an easy way to do so. > > > > Packagers use standard paths - so it never becomes a problem. > > > > If editing the file on the fly is not acceptable for the test script, > > then I'd suggest to fall back to the pkg-config option, and just > > document the need to use it in the docs for this scenarios. > > What I mean is that we should be able to compile our apps > after using DESTDIR, not related to the test script. > Can we use an environment variable like RTE_TARGET? DPDK_DIR? > We can certainly add one to our example Makefiles, it's just a couple of lines change to each one to add a prefix to the return value from pkg-config. I can attempt to do so in a later version of this patch, though I'd prefer to take more time over it than we have in 19.05. Alternatively, we can defer the last couple of patches in this set to 19.08, though again I'd prefer to have even this level of minimal testing of pkg-config into 19.05. Let me know what you think is best? /Bruce 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 A922AA0AC5 for ; Thu, 2 May 2019 17:30:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 944221B115; Thu, 2 May 2019 17:30:46 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 8E8C71B114 for ; Thu, 2 May 2019 17:30:44 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2019 08:30:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,422,1549958400"; d="scan'208";a="136257431" Received: from dshirizl-mobl1.ger.corp.intel.com ([10.252.11.108]) by orsmga007.jf.intel.com with SMTP; 02 May 2019 08:30:41 -0700 Received: by (sSMTP sendmail emulation); Thu, 02 May 2019 16:30:40 +0100 Date: Thu, 2 May 2019 16:30:40 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: Luca Boccassi , dev@dpdk.org Message-ID: <20190502153040.GA322@bricha3-MOBL.ger.corp.intel.com> References: <20190423220644.54589-1-bruce.richardson@intel.com> <20190502131738.GA1980@bricha3-MOBL.ger.corp.intel.com> <33cd0a15409b4af2d93bcfba804566ea09e7c0cb.camel@debian.org> <5943797.eKmBmZ8x9O@xps> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <5943797.eKmBmZ8x9O@xps> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 3/4] 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: <20190502153040.Q94nd5ToRy28Fld0hWzWnWxP_9wUzR7A6JIBciu3ZCY@z> On Thu, May 02, 2019 at 05:11:30PM +0200, Thomas Monjalon wrote: > 02/05/2019 16:08, Luca Boccassi: > > On Thu, 2019-05-02 at 14:17 +0100, Bruce Richardson wrote: > > > On Thu, May 02, 2019 at 03:11:10PM +0200, Thomas Monjalon wrote: > > > > 26/04/2019 16:56, Bruce Richardson: > > > > > On Wed, Apr 24, 2019 at 02:37:58PM +0100, Luca Boccassi wrote: > > > > > > On Wed, 2019-04-24 at 13:31 +0100, Bruce Richardson wrote: > > > > > > > On Wed, Apr 24, 2019 at 12:02:24PM +0100, Luca Boccassi > > > > > > > wrote: > > > > > > > > On Wed, 2019-04-24 at 11:41 +0100, Bruce Richardson wrote: > > > > > > > > > On Wed, Apr 24, 2019 at 10:22:04AM +0100, Luca Boccassi > > > > > > > > > wrote: > > > > > > > > > > On Tue, 2019-04-23 at 23:06 +0100, Bruce Richardson > > > > > > > > > > wrote: > > > > > > > > > > > +# > > > > > > > > > > > rather > > > > > > > > > > > than hacking our environment, just edit the .pc file > > > > > > > > > > > prefix > > > > > > > > > > > value > > > > > > > > > > > +sed > > > > > > > > > > > -i "s|prefix=|prefix=$DESTDIR|" > > > > > > > > > > > $PKG_CONFIG_PATH/libdpdk.pc > > > > > > > > > > > > > > > > > > > > What about just using meson's prefix option instead? > > > > > > > > > > Which is > > > > > > > > > > how > > > > > > > > > > it > > > > > > > > > > would be used in a real use case > > > > > > > > > > > > > > > > > > I don't think that would fully work, as my understanding > > > > > > > > > is that > > > > > > > > > the > > > > > > > > > prefix > > > > > > > > > option would apply only to the /usr/local parts, but not > > > > > > > > > to the > > > > > > > > > kernel > > > > > > > > > modules which would still try and install in /lib/. > > > > > > > > > > > > > > > > What about doing a meson configure -Denable_kmods=false > > > > > > > > before the > > > > > > > > ninja install? The modules are not needed for that test > > > > > > > > anyway, > > > > > > > > right? > > > > > > > > Alternatively, the kernel src dir could be symlinked in the > > > > > > > > build > > > > > > > > path, > > > > > > > > and the kernel_dir option could be used > > > > > > > > > > > > > > > > I'm just worried that the test should be as "realistic" as > > > > > > > > possible, to > > > > > > > > avoid missing something > > > > > > > > > > > > > > Yes, I did think of that too, but it does mean doing another > > > > > > > configuration > > > > > > > run in meson, and possibly a rebuild too if the > > > > > > > rte_build_config.h > > > > > > > file > > > > > > > changes. Therefore I decided to use DESTDIR for the sake of > > > > > > > speed > > > > > > > here. I > > > > > > > assumed there would be a pkg-config variable to adjust the > > > > > > > output > > > > > > > paths > > > > > > > based on a sysroot, but couldn't find a suitable one. > > > > > > > > [...] > > > > > > There actually is a pkg-config binary option, I just tried and > > > > > > it works > > > > > > (it seems to be disabled by default on Debian and derivatives): > > > > > > -- > > > > > > define-prefix > > > > > > > > > > > > > > > > Any cmdline options to pkg-config don't solve the problem here as > > > > > it means > > > > > that the makefiles for any app need to be modified to use all > > > > > those. > > > > > > > > It looks to be a good solution. > > > > Being able to update the DPDK install directory when building > > > > an application should be a mandatory requirement. > > > > I suggest to wrap the call to pkg-config so we can have this > > > > ability. > > > > > > > > > > I would have expected that this issue has already been solved for > > > packagers. I was surprised that I couldn't find an easy way to do so. > > > > Packagers use standard paths - so it never becomes a problem. > > > > If editing the file on the fly is not acceptable for the test script, > > then I'd suggest to fall back to the pkg-config option, and just > > document the need to use it in the docs for this scenarios. > > What I mean is that we should be able to compile our apps > after using DESTDIR, not related to the test script. > Can we use an environment variable like RTE_TARGET? DPDK_DIR? > We can certainly add one to our example Makefiles, it's just a couple of lines change to each one to add a prefix to the return value from pkg-config. I can attempt to do so in a later version of this patch, though I'd prefer to take more time over it than we have in 19.05. Alternatively, we can defer the last couple of patches in this set to 19.08, though again I'd prefer to have even this level of minimal testing of pkg-config into 19.05. Let me know what you think is best? /Bruce