From: David Marchand <david.marchand@redhat.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH 1/2] build: fail if explicitly requested lib is unbuildable
Date: Mon, 4 Sep 2023 15:38:16 +0200 [thread overview]
Message-ID: <CAJFAV8xej3gZoNqjNpGr9YAC8s6CA-741oujUtWmMzb_eCo2Aw@mail.gmail.com> (raw)
In-Reply-To: <ZPH41QeXBZD3iU2V@bricha3-MOBL.ger.corp.intel.com>
On Fri, Sep 1, 2023 at 4:44 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Fri, Sep 01, 2023 at 04:30:56PM +0200, David Marchand wrote:
> > On Fri, Sep 1, 2023 at 4:29 PM David Marchand <david.marchand@redhat.com> wrote:
> > >
> > > On Fri, Sep 1, 2023 at 4:23 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > >
> > > > When the user passes a list of desired libraries to build via the
> > > > "enable_libs" option, the expectation is that those libraries should be
> > > > part of the build. However, if those libs have either external or
> > > > internal dependencies, they still may be silently disabled, for example:
> > > > running "meson setup -Denable_libs=security build" will successfully
> > > > run, but the security lib will not be configured as "cryptodev" is
> > > > missing.
> > > >
> > > > We can fix this by setting a flag to indicate when the libraries are
> > > > specified via an enable_libs flag. If so, then we error out when a
> > > > library is unbuildable, giving a suitable error message. For the above
> > > > example case, the "meson setup" run fails with:
> > > >
> > > > Message: Disabling security [lib/security]: missing internal dependency "cryptodev"
> > > >
> > > > lib/meson.build:218:16: ERROR: Problem encountered: Cannot build explicitly requested lib "security".
> > > > Please add missing dependency "cryptodev" to "enable_libs" option
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > >
> > > I remember setting a enable_drivers=net/af_xdp on a system lacking
> > > libbpf-devel and not getting warned about its absence.
> > > So I suspect enable_drivers is affected by the same issue.
> >
> > Arf sorry, did not see it was a two patch series :-).
> >
> No problem.
>
> At least your response confirms to me that this is indeed a common issue,
> that could do with a solution. As I explain in patch 2, fixing for drivers
> is a little trickier than for libs, as for drivers we really need to take
> account of wildcards to avoid breaking people's existing builds. [Or, at
> minimum, my own builds! :-)].
>
> BTW: while we could look to handle wildcards for libs, I think their use is
> probably much more limited there, and I decided to go with the simplest
> possible solution instead.
We have categories (classes) of drivers, and for them, I can imagine
people using wildcards.
But for libraries, I don't see how wildcards could be used, so I think
we can ignore them for now (until proven wrong ;-).
Thanks Bruce, this series is also enhancing the situation for a user.
Like when wanting to enable explicity a driver or a library: the
explicit error message on the missing dependency is easier to catch
than scrolling back/parsing meson output.
I did not review in detail, but it lgtm for my few tests.
For the series,
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
next prev parent reply other threads:[~2023-09-04 13:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 14:23 Bruce Richardson
2023-09-01 14:23 ` [PATCH 2/2] build: fail if explicitly requested driver " Bruce Richardson
2023-09-01 15:41 ` Morten Brørup
2023-09-02 17:24 ` Patrick Robb
2023-09-14 9:42 ` Bruce Richardson
2023-09-01 14:29 ` [PATCH 1/2] build: fail if explicitly requested lib " David Marchand
2023-09-01 14:30 ` David Marchand
2023-09-01 14:44 ` Bruce Richardson
2023-09-04 13:38 ` David Marchand [this message]
2023-09-01 15:40 ` Morten Brørup
2023-09-14 9:53 ` Bruce Richardson
2023-09-19 15:57 ` Bruce Richardson
2023-09-21 7:01 ` David Marchand
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=CAJFAV8xej3gZoNqjNpGr9YAC8s6CA-741oujUtWmMzb_eCo2Aw@mail.gmail.com \
--to=david.marchand@redhat.com \
--cc=bruce.richardson@intel.com \
--cc=dev@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).