From: Bruce Richardson <bruce.richardson@intel.com>
To: Luca Boccassi <bluca@debian.org>
Cc: dev@dpdk.org, stable@dpdk.org
Subject: Re: [dpdk-stable] [PATCH 2/2] build: use dependency() instead of find_library()
Date: Mon, 7 Jan 2019 14:28:12 +0000 [thread overview]
Message-ID: <20190107142812.GB14912@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20190103175725.5836-2-bluca@debian.org>
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 <bluca@debian.org>
> ---
>
> 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
>
next prev parent reply other threads:[~2019-01-07 14:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 17:57 [dpdk-stable] [PATCH 1/2] build: use static deps of libs for pkg-config libs.private Luca Boccassi
2019-01-03 17:57 ` [dpdk-stable] [PATCH 2/2] build: use dependency() instead of find_library() Luca Boccassi
2019-01-07 14:28 ` Bruce Richardson [this message]
2019-01-07 16:39 ` Luca Boccassi
2019-01-07 16:55 ` Bruce Richardson
2019-01-07 17:03 ` [dpdk-stable] [dpdk-techboard] " Thomas Monjalon
2019-01-07 17:45 ` Thomas Monjalon
2019-01-11 11:10 ` [dpdk-stable] [dpdk-dev] " Luca Boccassi
2019-01-11 11:52 ` Bruce Richardson
2019-01-11 12:39 ` Luca Boccassi
2019-01-11 14:24 ` Bruce Richardson
2019-01-11 14:56 ` Luca Boccassi
2019-01-11 15:49 ` Bruce Richardson
2019-01-11 16:27 ` Luca Boccassi
2019-01-11 12:38 ` [dpdk-stable] [PATCH v2 1/3] build: use static deps of libs for pkg-config libs.private Luca Boccassi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190107142812.GB14912@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=bluca@debian.org \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).