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 4FF3C4C8B; Mon, 7 Jan 2019 15:28:17 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2019 06:28:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,451,1539673200"; d="scan'208";a="136032812" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.54]) by fmsmga001.fm.intel.com with SMTP; 07 Jan 2019 06:28:13 -0800 Received: by (sSMTP sendmail emulation); Mon, 07 Jan 2019 14:28:12 +0000 Date: Mon, 7 Jan 2019 14:28:12 +0000 From: Bruce Richardson To: Luca Boccassi Cc: dev@dpdk.org, stable@dpdk.org Message-ID: <20190107142812.GB14912@bricha3-MOBL.ger.corp.intel.com> References: <20190103175725.5836-1-bluca@debian.org> <20190103175725.5836-2-bluca@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190103175725.5836-2-bluca@debian.org> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH 2/2] build: use dependency() instead of find_library() 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: Mon, 07 Jan 2019 14:28:18 -0000 On Thu, Jan 03, 2019 at 06:57:25PM +0100, Luca Boccassi wrote: > Whenever possible (if the library ships a pkg-config file) use meson's > dependency() function to look for it, as it will automatically add it > to the Requires.private list if needed, to allow for static builds to > succeed for reverse dependencies of DPDK. Otherwise the recursive > dependencies are not parsed, and users doing static builds have to > resolve them manually by themselves. > When using this API avoid additional checks that are superfluos and > take extra time, and avoid adding the linker flag manually which causes > it to be duplicated. > > An internal checker has been added to Meson 0.42 to detect libpcap, > which ships a custom tool rather than a pkg-config file, so bump the > minimum Meson version from 0.41 to 0.42. If we are going to bump the version, I think we should bump it further to e.g. 0.46 or 0.47 unless there is anyone who still wants an earlier version. That should get rid of a number of the meson version warnings we see on each run. > > For libbsd, which is checked in a top level file and used to be added > to the global linker flags array, add it to the ext_deps array of > all top level meson files (app, test, lib, examples, drivers). The > most correct change would be to let each individual library/driver/app > depend on it individually if they use symbols from it, but it would > diverge from the legacy Makefile's behaviour and make life a bit more > difficult for contributors. It shouldn't be necessary to add libbsd as a dependency for everything. I think just adding it as a dependency of EAL should work fine. However, in conjunction with meson version checks, I believe this was done this way originally because of a meson bug which caused recursive dependencies for things like this to get duplicated many times in the build.ninja file. https://github.com/mesonbuild/meson/issues/2150 If we take the approach of adding bsd explicitly using dependency object our minimum version needs to have the fix for this bug included. > > Fixes: a25a650be5f0 ("build: add infrastructure for meson and ninja builds") > Cc: stable@dpdk.org > > Signed-off-by: Luca Boccassi > --- > > Bruce, dependency() by default tries pkg-config first, then cmake, then > the internal project-specific finders (like pcap). If you think it's > worth it I can add fallbacks in case a system, for whatever reason, > does not install a pc file despite the upstream project providing one. > It would add more clutter and more verbosity, but it would not cause > other issues. I'd prefer to keep it without that for now. If the lack of .pc files causes issues we can revisit. /Bruce >