From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 164E2A0535;
Tue, 4 Feb 2020 15:33:22 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 31DF61C1BC;
Tue, 4 Feb 2020 15:33:21 +0100 (CET)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id C698E1C0BC
for <dev@dpdk.org>; Tue, 4 Feb 2020 15:33:19 +0100 (CET)
X-Amp-Result: UNSCANNABLE
X-Amp-File-Uploaded: False
Received: from orsmga008.jf.intel.com ([10.7.209.65])
by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
04 Feb 2020 06:33:18 -0800
X-IronPort-AV: E=Sophos;i="5.70,402,1574150400"; d="scan'208";a="224310455"
Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.79])
by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA;
04 Feb 2020 06:33:17 -0800
Date: Tue, 4 Feb 2020 14:33:14 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org
Message-ID: <20200204143314.GA679@bricha3-MOBL.ger.corp.intel.com>
References: <20200116071656.1663967-1-thomas@monjalon.net>
<20200127154402.4008069-1-thomas@monjalon.net>
<20200204114838.GC637@bricha3-MOBL.ger.corp.intel.com>
<5323608.DvuYhMxLoT@xps>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5323608.DvuYhMxLoT@xps>
User-Agent: Mutt/1.12.1 (2019-06-15)
Subject: Re: [dpdk-dev] [PATCH v2 0/4] add static ibverbs in meson
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Tue, Feb 04, 2020 at 03:27:50PM +0100, Thomas Monjalon wrote:
> 04/02/2020 12:48, Bruce Richardson:
> > as we discussed offline, I really don't like the necessity of the
> > hidden_deps part of this, so I've tried coming up with some other
> > solutions.
>
> Thanks for looking closely at these patches.
>
> > For example, in my testing I get the same result with the
> > following diff instead of the second two patches (just showing for mlx5 -
> > changes for mlx4 are identical):
> [...]
> > - # Build without adding shared libs to Requires.private
> > - hidden_deps += lib.partial_dependency(compile_args:true)
> [...]
> > + ibv_cflags = run_command(find_program('pkg-config'), '--cflags', 'libibverbs').stdout()
> [...]
> > By doing things this way - assuming it works in your tests too - we avoid
> > any need to change anything in the common drivers code.
>
> Yes, you hide the dependency by getting cflags directly with pkg-config.
> I wanted to avoid such solution because I was trying to use as much
> as possible the meson infrastructure.
>
> I think your solution relying on one more call to pkg-config is acceptable.
> I will test it and will review whether we get all corner cases.
>
Thanks.
It's not really ideal, but this is likely always going to be a bit flakey
since we can't use distro-supplied .a files, and your scripting is needed
to prevent even accidentally taking a non-custom-build rdma-core file.
Furthermore, I see that while meson tracks PKG_CONFIG_PATH value itself for
finding things, this does not get tracked between runs for shell calls.
This can catch one out, for example:
PKG_CONFIG_PATH=/path/to/pc/files meson build
will work correctly for everything. However, if one does a reconfigure
subsequently doing e.g. ninja reconfigure, meson will correctly pick up the
.pc files, but the ibverbs-static script, or any run_command calls to
pkg-config won't as it's not actually in the environment :-(
> In the meantime I discovered we are overlinking with meson
> when using the dlopen linking option.
> I will try to fix it as well with the same method.
>
Right. Overlinking is probably less serious an issue though. Does it cause
any real-world problems?
/Bruce