From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id F3C031B277 for ; Fri, 26 Apr 2019 16:56:11 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 07:56:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,397,1549958400"; d="scan'208";a="341045943" Received: from dlubczyn-mobl.ger.corp.intel.com ([10.252.15.248]) by fmsmga005.fm.intel.com with SMTP; 26 Apr 2019 07:56:08 -0700 Received: by (sSMTP sendmail emulation); Fri, 26 Apr 2019 15:56:07 +0100 Date: Fri, 26 Apr 2019 15:56:07 +0100 From: Bruce Richardson To: Luca Boccassi Cc: dev@dpdk.org Message-ID: <20190426144838.GA26084@bsd12> References: <20190423220644.54589-1-bruce.richardson@intel.com> <20190423220644.54589-4-bruce.richardson@intel.com> <8e3b35cd842729263299466a5cfb34f37d6dd729.camel@debian.org> <20190424104119.GB1885@bricha3-MOBL.ger.corp.intel.com> <20190424123105.GA1892@bricha3-MOBL.ger.corp.intel.com> <181e25f512b11f6c691f58c2cfdf47a9322a5091.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <181e25f512b11f6c691f58c2cfdf47a9322a5091.camel@debian.org> 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: Fri, 26 Apr 2019 14:56:12 -0000 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: > > > > > > 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 < > > > > > > bruce.richardson@intel.com > > > > > > > > > > > > > > > > > > > > > > > > --- devtools/test-meson-builds.sh | 17 +++++++++++++++++ 1 > > > > > > file > > > > > > changed, 17 insertions(+) > > > > > > > > > > > > diff --git a/devtools/test-meson-builds.sh b/devtools/test- > > > > > > meson- > > > > > > builds.sh index 630a1a6fe..dfba2a782 100755 --- > > > > > > a/devtools/test-meson-builds.sh +++ b/devtools/test-meson- > > > > > > builds.sh @@ > > > > > > -90,3 +90,20 @@ if command -v $c >/dev/null 2>&1 ; then > > > > > > $use_shared > > > > > > --cross-file $f done fi + +############## +# 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 > > > > > > +############### > > > > > > +build_path=build-x86-default > > > > > > +DESTDIR=`pwd`/$build_path/install- > > > > > > root ; > > > > > > export DESTDIR > > > > > > +PKG_CONFIG_PATH=$DESTDIR/usr/local/lib64/pkgconfig ; > > > > > > export PKG_CONFIG_PATH +$ninja_cmd -C $build_path install + > > > > > > +# > > > > > > 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/. > > > > > > > > /Bruce > > > > > > 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. > > > > In any case, I'll see about changing things as you suggest in V2 - > > correctness is more important that speed here. > > > > /Bruce > > 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. Also, I've been looking at the option you suggest of disabling the kernel modules for the install step - the problem that this brings is that it either: * disables them permanently for the default build, meaning subsequent runs may fail to catch errors * causes us to constantly reconfigure the build directory with/without the kmod setting, causing unnecessary work and slowdown in the script. A third solution is to use a separate build folder for the pkg-config test builds, but I think we have enough builds already in the setup without adding another one. All-in-all, I feel at this point that the original solution of making a small change to the pkg-config file manually is the best solution for now. I don't see it as being terribly fragile, and it should catch 95% of problems with the pkg-config files. I suggest that any rework be looked at in a later set to improve things. Regards, /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 2EA11A05D3 for ; Fri, 26 Apr 2019 16:56:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EB8081B28B; Fri, 26 Apr 2019 16:56:13 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id F3C031B277 for ; Fri, 26 Apr 2019 16:56:11 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 07:56:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,397,1549958400"; d="scan'208";a="341045943" Received: from dlubczyn-mobl.ger.corp.intel.com ([10.252.15.248]) by fmsmga005.fm.intel.com with SMTP; 26 Apr 2019 07:56:08 -0700 Received: by (sSMTP sendmail emulation); Fri, 26 Apr 2019 15:56:07 +0100 Date: Fri, 26 Apr 2019 15:56:07 +0100 From: Bruce Richardson To: Luca Boccassi Cc: dev@dpdk.org Message-ID: <20190426144838.GA26084@bsd12> References: <20190423220644.54589-1-bruce.richardson@intel.com> <20190423220644.54589-4-bruce.richardson@intel.com> <8e3b35cd842729263299466a5cfb34f37d6dd729.camel@debian.org> <20190424104119.GB1885@bricha3-MOBL.ger.corp.intel.com> <20190424123105.GA1892@bricha3-MOBL.ger.corp.intel.com> <181e25f512b11f6c691f58c2cfdf47a9322a5091.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <181e25f512b11f6c691f58c2cfdf47a9322a5091.camel@debian.org> 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: <20190426145607.T_H0sr2x5dgOTOMT71KURpZiiZjg-JN0-eU1SjULQFE@z> 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: > > > > > > 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 < > > > > > > bruce.richardson@intel.com > > > > > > > > > > > > > > > > > > > > > > > > --- devtools/test-meson-builds.sh | 17 +++++++++++++++++ 1 > > > > > > file > > > > > > changed, 17 insertions(+) > > > > > > > > > > > > diff --git a/devtools/test-meson-builds.sh b/devtools/test- > > > > > > meson- > > > > > > builds.sh index 630a1a6fe..dfba2a782 100755 --- > > > > > > a/devtools/test-meson-builds.sh +++ b/devtools/test-meson- > > > > > > builds.sh @@ > > > > > > -90,3 +90,20 @@ if command -v $c >/dev/null 2>&1 ; then > > > > > > $use_shared > > > > > > --cross-file $f done fi + +############## +# 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 > > > > > > +############### > > > > > > +build_path=build-x86-default > > > > > > +DESTDIR=`pwd`/$build_path/install- > > > > > > root ; > > > > > > export DESTDIR > > > > > > +PKG_CONFIG_PATH=$DESTDIR/usr/local/lib64/pkgconfig ; > > > > > > export PKG_CONFIG_PATH +$ninja_cmd -C $build_path install + > > > > > > +# > > > > > > 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/. > > > > > > > > /Bruce > > > > > > 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. > > > > In any case, I'll see about changing things as you suggest in V2 - > > correctness is more important that speed here. > > > > /Bruce > > 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. Also, I've been looking at the option you suggest of disabling the kernel modules for the install step - the problem that this brings is that it either: * disables them permanently for the default build, meaning subsequent runs may fail to catch errors * causes us to constantly reconfigure the build directory with/without the kmod setting, causing unnecessary work and slowdown in the script. A third solution is to use a separate build folder for the pkg-config test builds, but I think we have enough builds already in the setup without adding another one. All-in-all, I feel at this point that the original solution of making a small change to the pkg-config file manually is the best solution for now. I don't see it as being terribly fragile, and it should catch 95% of problems with the pkg-config files. I suggest that any rework be looked at in a later set to improve things. Regards, /Bruce