On Mon, Jun 19, 2023 at 4:26 PM Bruce Richardson
<bruce.richard...@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.march...@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.

>
> > 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.


-- 
David Marchand

Reply via email to