> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Monday, 29 August 2022 12.41 > > On Fri, Aug 26, 2022 at 05:46:48PM +0200, Morten Brørup wrote: > > > > Also, there's a new discussion about EAL bloat [1]. Perhaps I'm > stretching it here, but it would be nice if your library was made a > separate library, instead of part of the EAL library. (Since this kind > of feature is not new to the EAL, I will categorize this suggestion as > "nice to have", not "must have".) > > > > [1] http://inbox.dpdk.org/dev/2594603.Isy0gbHreE@thomas/T/ > > > > I was actually discussing this with Kevin and Dave H. on Friay, and > trying > to make this a separate library is indeed a big stretch. :-) > > From that discussion, the key point/gap is that we are really missing a > clean way of providing undefs or macro fallbacks for when a library is > just > not present. For example, if this was a separate library we would gain > a > number of advantages e.g. no need for separate enable/disable flag, but > the > big disadvantage is that every header include for it, and every > reference > to the macros used in that header need to be surrounded by big ugly > ifdefs.
I agree that we don't want everything surrounded by big ugly ifdefs. I think solving this should be the responsibility of a library itself, not of the application or other libraries. E.g. like the mbuf library's use of RTE_LIBRTE_MBUF_DEBUG. Additionally, a no-op variant of the library could be required, to be compiled in when the library is disabled at build time. > > For now, adding this into EAL is the far more practical approach, since > it > means that even if support for the feature is disabled at build time > the > header is still available to provide the appropriate no-op macros. I think you already discovered the key to solving this problem, but perhaps didn't even notice it yourselves: It must be possible to omit the *feature* at build time - not necessarily the *library*.
