2021-03-01 21:31, Nick Connolly: > > There's a meson issue with `cc.has_function()`: > > https://github.com/mesonbuild/meson/issues/5628 > > > > What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h > > (and other public headers if need be) to distinguish the case when it's used > > from within DPDK? > It's a pragmatic solution to the problem, but sadly it's not quite as > clean as letting the build system determine if each 'wrapper' is needed. > DPDK supports a variety of platforms and toolsets and my experience with > SPDK suggests that we'll end up with compiler specific ifdef's.
I'd argue they are inevitable. Consider POSIX close(): if it's missing, what would be a correct fallback? It depends on the execution environment (OS). String function fallbacks, of course, are easily implemented from scratch. > It's all > protected by RTE_INTERNAL so it's not really a problem, but I wonder if > it makes it easier for someone to accidentally introduce definitions > outside of the #ifdef RTE_INTERNAL? Public functions without rte_ prefix shall not be introduced at all. Remember the issue this patchset targets: export of POSIX symbols from EAL. They are already defined in a way DPDK consumes successfully. RTE_INTERNAL is a straightforward way to ensure symbols affect to other consumers. (I'm talking about macros; asprintf should be moved inside EAL in any case.)
