Re: [PATCH v4 3/4] build: select deprecated libraries

[David Marchand <david.marchand@redhat.com>]

On Fri, Jun 23, 2023 at 1:33 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > > > > - I don't have a usage for this, but if we go with separating
> > > > > deprecated and "normal" optional libs filtering, should I introduce a
> > > > > disable_deprecated_libs too?
> > > > >
> > > >
> > > > That would give us *way* to many options. I think for the sake of
> > simplicity
> > > > we probably are as well to just go with what you are proposing in this
> > set.
> > > > Since we only have two deprecated libraries - and hopefully never many
> > more -
> > > > the benefit of the list for that setting is probably minimal. I'm keen to
> > > > avoid too much complexity if we can manage it.
> > >
> > > I strongly agree with Bruce about avoiding too many options. Here's an idea:
> > >
> > > How about just having the disable/enable_libs options, and by default omit
> > the deprecated libs.
> > >
> > > Then, the deprecated libs can be enabled by using the enable_libs option.
> > >
> >
> > That was the original suggestion and implementation. The trouble is that
> > if you specify, for example, -Denable_libs=kni, you have just disabled
> > every other optional library in DPDK, since the enable_libs option switches
> > DPDK to "allowlist"-only mode.
>
> OK. Hmmm.... Perhaps we can accept that, using this argument:
>
> If you are in a situation where you are using some deprecated libs, you probably also know exactly which other optional libs you are using. So you must specify the full list on enable_libs.
>
> I won't object if anyone disagrees with this idea. I'm only trying to keep it simple. :-)

- Mixing deprecated and "normal" libraries in a single generic option
means that people (who are selecting some optional libraries only atm)
could miss when an optional library is deprecated (in the future).
On the other hand, if we go with a specialised option for deprecated
libs, users will have to explicitly ask for keeping them.
I think it is also clearer from a user pov.

So I would stick with a separate handling of normal and deprecated libs.

- Adding a disable_deprecated_libs option does not make much sense for
only two libraries.

- For v23.07, I'll announce a change in behavior in the build system
wrt deprecated libraries.

I'll respin on top of Bruce idea (implementing enable_deprecated_libs
as a list) for now.
And we can conclude on how to best expose/configure this by v23.11.


-- 
David Marchand