Re: [PATCH v3] build: select optional libraries

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Jun 20, 2023 at 04:33:15PM +0200, Thomas Monjalon wrote:
> 20/06/2023 11:03, Bruce Richardson:
> > On Tue, Jun 20, 2023 at 10:48:50AM +0200, David Marchand wrote:
> > > On Tue, Jun 20, 2023 at 10:45 AM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > > > > > > 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.
> > > > >
> > > > > Thomas, wdyt?
> > > > > It requires some release note, at least.
> > > > >
> > > > I am assuming this is not targetting this release though, right? Assuming
> > > > 23.11, we can put in a deprecation note informing of the change ahead of
> > > > time too.
> > > 
> > > I was hoping to get it in this release.
> > > But I am fine with postponing and announcing the change beforehand.
> > > 
> > Given the fact that we are likely changing behaviour, and the fact that the
> > deprecated libs makes it more complicated than the drivers one (since we
> > have always on, default on and default off cases to consider), I think it's
> > best we don't rush this.
> 
> I'm not sure what is the best behaviour.
> I tend to think such options should be simple to understand
> with only 3 cases:
> - no option -> default
> - enable option -> only core mandatory and listed libraries
> - disable option -> all but the listed libraries
> It looks simpler to forbid having both enable and disable libraries.
> 
> Would you be open to change the behaviour of the drivers options?
> 
Yes, no issue there. I don't see a problem with disallowing having both
enable and disable options set.