On Fri, Sep 1, 2023 at 4:44 PM Bruce Richardson <bruce.richard...@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.march...@redhat.com> > > wrote: > > > > > > On Fri, Sep 1, 2023 at 4:23 PM Bruce Richardson > > > <bruce.richard...@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.richard...@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.march...@redhat.com> -- David Marchand
