From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 74D741B6EF for ; Fri, 26 Apr 2019 18:10:19 +0200 (CEST) Received: by mail-wr1-f67.google.com with SMTP id b1so5202224wru.3 for ; Fri, 26 Apr 2019 09:10:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=m3Y0ikfAL7r930VByOoqEAHUE/uAab6sbYTt/1YpEyA=; b=iRCDxUnm8bBIG/J4fhxp2NTnx3UG5Gqfhyo+eFaKsWfiY21HOvcrEG7rCOUbunzE0R STXEiYZ+QCF+sR4oXm8ET2fCaTzdHjY9lC59QTjXbzbU0ToP5wbw58NdUpVSMlHkAkrl jkGCZNfZoRq5NwdOK0S7oO3ivJRl6OUGnf03BP2wIcSAYTgQeTjoTuJHNqKjQCgFGqg+ 6NpCVmuiZrxaGqRDQHeRn8OvBoi0qbWJeBV5ov4JxmJ7FjUvVy+WZSesfQjqHDbhpgJr T2pskTAWKm6mQHTd4G5M4hM0g2fDxIL9F4gq2YVz237GJ41quqC7n01zPGKYIpSjloXN UrCQ== X-Gm-Message-State: APjAAAWAmeib9MBAXtLJ0vs8ULoBkbJC9/ED2TGG3IgbGCEGKPTMpemx uqKdncfk60CQ+HYSmQVNKPQ= X-Google-Smtp-Source: APXvYqx4c15x3NwsvtcZLE2QIB+aAi9Jmet+DKl93R1038ZCXzeGORCcsiAOtwZPkxZmpXsu6AG+8Q== X-Received: by 2002:a5d:6988:: with SMTP id g8mr9787613wru.117.1556295019054; Fri, 26 Apr 2019 09:10:19 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id i2sm24666583wmg.47.2019.04.26.09.10.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 09:10:17 -0700 (PDT) Message-ID: From: Luca Boccassi To: Bruce Richardson Cc: dev@dpdk.org Date: Fri, 26 Apr 2019 17:10:17 +0100 In-Reply-To: <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> <20190426144838.GA26084@bsd12> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 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 16:10:19 -0000 On Fri, 2019-04-26 at 15:56 +0100, Bruce Richardson wrote: > 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. > > > > > > >=20 > > > > > > > Signed-off-by: Bruce Richardson <=20 > > > > > > > bruce.richardson@intel.com > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > --- devtools/test-meson-builds.sh | 17 +++++++++++++++++ > > > > > > > 1 > > > > > > > file > > > > > > > changed, 17 insertions(+) > > > > > > >=20 > > > > > > > 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=3Dbuild-x86-default > > > > > > > +DESTDIR=3D`pwd`/$build_path/install- > > > > > > > root ; > > > > > > > export DESTDIR > > > > > > > +PKG_CONFIG_PATH=3D$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=3D|prefix=3D$DESTDIR|" > > > > > > > $PKG_CONFIG_PATH/libdpdk.pc > > > > > >=20 > > > > > > What about just using meson's prefix option instead? Which > > > > > > is > > > > > > how > > > > > > it > > > > > > would be used in a real use case > > > > > >=20 > > > > >=20 > > > > > 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/. > > > > >=20 > > > > > /Bruce > > > >=20 > > > > What about doing a meson configure -Denable_kmods=3Dfalse 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 > > > >=20 > > > > I'm just worried that the test should be as "realistic" as > > > > possible, to > > > > avoid missing something > > > >=20 > > >=20 > > > 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. > > >=20 > > > In any case, I'll see about changing things as you suggest in V2 > > > - > > > correctness is more important that speed here. > > >=20 > > > /Bruce > >=20 > > 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 > >=20 >=20 > 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. >=20 > 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. >=20 > A third solution is to use a separate build folder for the pkg-config=20 > test > builds, but I think we have enough builds already in the setup > without adding > another one. >=20 > 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. >=20 > Regards, > /Bruce Makes sense, I had hoped it would be easier - thanks for giving it a shot! --=20 Kind regards, Luca Boccassi 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 7F2D2A05D3 for ; Fri, 26 Apr 2019 18:10:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CE7EE1B6F0; Fri, 26 Apr 2019 18:10:20 +0200 (CEST) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 74D741B6EF for ; Fri, 26 Apr 2019 18:10:19 +0200 (CEST) Received: by mail-wr1-f67.google.com with SMTP id b1so5202224wru.3 for ; Fri, 26 Apr 2019 09:10:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=m3Y0ikfAL7r930VByOoqEAHUE/uAab6sbYTt/1YpEyA=; b=iRCDxUnm8bBIG/J4fhxp2NTnx3UG5Gqfhyo+eFaKsWfiY21HOvcrEG7rCOUbunzE0R STXEiYZ+QCF+sR4oXm8ET2fCaTzdHjY9lC59QTjXbzbU0ToP5wbw58NdUpVSMlHkAkrl jkGCZNfZoRq5NwdOK0S7oO3ivJRl6OUGnf03BP2wIcSAYTgQeTjoTuJHNqKjQCgFGqg+ 6NpCVmuiZrxaGqRDQHeRn8OvBoi0qbWJeBV5ov4JxmJ7FjUvVy+WZSesfQjqHDbhpgJr T2pskTAWKm6mQHTd4G5M4hM0g2fDxIL9F4gq2YVz237GJ41quqC7n01zPGKYIpSjloXN UrCQ== X-Gm-Message-State: APjAAAWAmeib9MBAXtLJ0vs8ULoBkbJC9/ED2TGG3IgbGCEGKPTMpemx uqKdncfk60CQ+HYSmQVNKPQ= X-Google-Smtp-Source: APXvYqx4c15x3NwsvtcZLE2QIB+aAi9Jmet+DKl93R1038ZCXzeGORCcsiAOtwZPkxZmpXsu6AG+8Q== X-Received: by 2002:a5d:6988:: with SMTP id g8mr9787613wru.117.1556295019054; Fri, 26 Apr 2019 09:10:19 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id i2sm24666583wmg.47.2019.04.26.09.10.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 09:10:17 -0700 (PDT) Message-ID: From: Luca Boccassi To: Bruce Richardson Cc: dev@dpdk.org Date: Fri, 26 Apr 2019 17:10:17 +0100 In-Reply-To: <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> <20190426144838.GA26084@bsd12> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 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: <20190426161017.YttkKbJJLdZmViUQ1gkxoeQ7PC82aDWnpaJtkQCGWZk@z> On Fri, 2019-04-26 at 15:56 +0100, Bruce Richardson wrote: > 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. > > > > > > >=20 > > > > > > > Signed-off-by: Bruce Richardson <=20 > > > > > > > bruce.richardson@intel.com > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > --- devtools/test-meson-builds.sh | 17 +++++++++++++++++ > > > > > > > 1 > > > > > > > file > > > > > > > changed, 17 insertions(+) > > > > > > >=20 > > > > > > > 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=3Dbuild-x86-default > > > > > > > +DESTDIR=3D`pwd`/$build_path/install- > > > > > > > root ; > > > > > > > export DESTDIR > > > > > > > +PKG_CONFIG_PATH=3D$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=3D|prefix=3D$DESTDIR|" > > > > > > > $PKG_CONFIG_PATH/libdpdk.pc > > > > > >=20 > > > > > > What about just using meson's prefix option instead? Which > > > > > > is > > > > > > how > > > > > > it > > > > > > would be used in a real use case > > > > > >=20 > > > > >=20 > > > > > 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/. > > > > >=20 > > > > > /Bruce > > > >=20 > > > > What about doing a meson configure -Denable_kmods=3Dfalse 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 > > > >=20 > > > > I'm just worried that the test should be as "realistic" as > > > > possible, to > > > > avoid missing something > > > >=20 > > >=20 > > > 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. > > >=20 > > > In any case, I'll see about changing things as you suggest in V2 > > > - > > > correctness is more important that speed here. > > >=20 > > > /Bruce > >=20 > > 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 > >=20 >=20 > 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. >=20 > 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. >=20 > A third solution is to use a separate build folder for the pkg-config=20 > test > builds, but I think we have enough builds already in the setup > without adding > another one. >=20 > 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. >=20 > Regards, > /Bruce Makes sense, I had hoped it would be easier - thanks for giving it a shot! --=20 Kind regards, Luca Boccassi