[PATCH v3] build: select optional libraries
Bruce Richardson
bruce.richardson at intel.com
Tue Jun 20 10:35:40 CEST 2023
On Tue, Jun 20, 2023 at 10:31:19AM +0200, David Marchand wrote:
> On Mon, Jun 19, 2023 at 4:26 PM Bruce Richardson
> <bruce.richardson at intel.com> wrote:
> >
> > On Mon, Jun 19, 2023 at 04:11:37PM +0200, David Marchand wrote:
> > > On Fri, Jun 16, 2023 at 9:21 AM David Marchand
> > > <david.marchand at redhat.com> wrote:
> > > > @@ -141,13 +137,25 @@ foreach l:libraries
> > > > deps += ['eal']
> > > > endif
> > > >
> > > > - if disabled_libs.contains(l)
> > > > + if not enable_libs.contains(l)
> > > > + build = false
> > > > + reason = 'not in enabled libraries build config'
> > > > + elif disable_libs.contains(l)
> > > > build = false
> > > > reason = 'explicitly disabled via build config'
> > > > - if dpdk_libs_deprecated.contains(l)
> > > > + endif
> > >
> > > There is also a change in behavior for current users of the
> > > -Ddisable_libs= configuration (which was used for enabling deprecated
> > > libraries, for example).
> >
> > I notice the change in behaviour for enabling the deprecated libs. Is there
> > any other change in behaviour for current users?
>
> The only change I see, is that this implementation breaks enabling
> deprecated libs via disable_libs.
> It may break existing developer build directory and maybe some
> packaging scripts, this is why I am a bit puzzled.
>
> Relooking at the disable_libs option current implementation, it seems
> backward to pass a disable_libs option when you want to build some
> deprecated library.
> It is more straightforward to request building libraries via
> -Denable_libs=<deprecated_lib> explicitly or -Denable_libs=*
> implicitly.
>
> But again, we may be breaking something for people who relied on this behavior.
>
That's what I expected, and I think that is ok. I just wanted to check that
the change in behaviour was only for the deprecated libs case.
> >
> > > My current solution resides in making disable_libs and enable_libs
> > > options being mutually exclusive (meaning that presence of a value for
> > > enable_libs will ignore any configuration around disable_libs).
> > >
> > > Does it look ok to you?
> > >
> > Do we need to make them mutually exclusive? The current drivers
> > implementation allows them to be used together, I think.
>
> I would prefer we are consistent with the drivers options.
>
Yep, I definitely agree. Both drivers and libs should have the same
behaviour.
More information about the dev
mailing list