18/02/2024 17:38, Morten Brørup: > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Sunday, 18 February 2024 16.35 > > > > 18/02/2024 13:53, Morten Brørup: > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > Sent: Sunday, 18 February 2024 13.24 > > > > > > > > 15/02/2024 23:20, Tyler Retzlaff: > > > > > Provide a new macro __rte_attribute(a) that when directly used > > > > > compiles to empty for MSVC and to __attribute__(a) when using > > > > GCC/LLVM. > > > > > > > > > > Replace direct use of __attribute__ in __rte_xxx macros where > > there > > > > is > > > > > existing empty expansion of the macro for MSVC allowing removal > > of > > > > > repeated #ifdef RTE_TOOLCHAIN_MSVC per macro to expand empty. > > > > > > > > I'm not sure it makes sense. > > > > I prefer seeing clearly what is empty with MSVC. > > > > > > This topic has previously been discussed in another context - adding > > external libraries [1]. > > > > > > Like you do here, I generally preferred #ifdefs in the code, but the > > majority preferred stubs "promoting improved code readability". > > > > Stubs may make sense in many places, > > but here we are talking about rte_common.h > > where we abstract differences between arch and compilers, > > so it is the right place to be explicit with compilers support. > > Very strong point. I'm convinced. > > Should the new rte_attribute() macro still be introduced for other uses of > __attribute__(), e.g. the somewhat exotic attributes in > eal/include/rte_lock_annotations.h?
They are all wrapped in a meaningful macro. > The not-so-exotic attributes could have new macros added, e.g. __rte_const > and __rte_pure. Yes we need wrappers for all attributes. > > > I might argue that Tyler is following that guidance here; and perhaps > > the decision should be reconsidered, now that we have a real-life > > example of how it affects code readability. ;-) > > > > > > [1]: https://inbox.dpdk.org/dev/20240109141009.497807-1- > > jer...@marvell.com/
