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