On Fri, Mar 14, 2025 at 5:53 PM David Marchand <david.march...@redhat.com> wrote: > > On Fri, Mar 14, 2025 at 5:24 PM Bruce Richardson > <bruce.richard...@intel.com> wrote: > > > > On Fri, Mar 14, 2025 at 05:14:34PM +0100, David Marchand wrote: > > > On Thu, Mar 13, 2025 at 6:31 PM Bruce Richardson > > > <bruce.richard...@intel.com> wrote: > > > > > > > > On Tue, Mar 11, 2025 at 10:56:04AM +0100, David Marchand wrote: > > > > > Annotate symbols with newly introduced export macros. > > > > > > > > > > For code not compiled by lib/meson.build or drivers/meson.build (like > > > > > AVX > > > > > separate libraries, or sources in /base/ drivers), the exported > > > > > symbols > > > > > are added in some file listed in the sources so they get caught by > > > > > lib/meson.build or drivers/meson.build. > > > > > > > > > > Signed-off-by: David Marchand <david.march...@redhat.com> > > > > > --- > > > > > > > > Just checking: for the AVX2 and similar instruction-set-specific > > > > functions, > > > > we don't get errors if those are not present in the actual link phase, > > > > e.g. > > > > when building on non-x86 platforms? We don't need to put an #ifdef > > > > around > > > > the exports? > > > > > > We are not there yet, but it is likely MSVC linker will complain, indeed. > > > > > > #ifdef around the exports won't work, we would need a precompiler pass > > > (and exclude rte_exports.h inclusion). > > > > > > Another option would be to provide stubs for those symbols when the > > > additional AVX512 (for example) libraries are not compiled. > > > > > > But I think the simpler is to let a driver/library provide a set of > > > sources to parse for exports... maybe via an extra variable? > > > WDYT? > > > > > Yes, something like that could work. > > > > What I'd actually like more, but never have had time to actually try out is > > to generalise the instruction-set-specific build stuff into the higher level > > drivers/meson.build code. After all, much of the code for doing so is just > > duplicated - check for AVX512 or AVX2 and if present build these files with > > the extra flags for that instruction set. > > > > Something similar with the base code. Most base code builds follow pretty > > much the exact same routine. > > Having those separate libraries require special cases every time, so > yes, it would be great if those could be factored in some shared > mechanism in drivers/meson.build. > > Putting the AVX stuff aside, and back to why we need those separate > libraries for base drivers... I think the main use is to waive some > build warnings, is there something else? > If so.. I think some drivers could already be cleaned (like net/e1000, > net/ngbe, net/octeontx, net/thunderx, net/txgbe, raw/ifpga at a first > glance). > > The AVX stuff seems a bit more complex, as there are multiple combinations...
CFLAGS_file.o += -Wno-stuff was so handy ... :-) -- David Marchand
