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