> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com] > Sent: Wednesday, 5 April 2023 12.57 > > > > >>Another ore generic comment - do we really need to pollute all that code > with RTE_TOOLCHAIN_MSVC ifdefs? > > > >>Right now we have ability to have subdir per arch (x86/arm/etc.). > > > >>Can we treat x86+windows+msvc as a special arch? > > > > > > > >i asked this question previously and confirmed in the technical board > > > >meeting. the answer i received was that the community did not want new > > > >directory/headers introduced for compiler support matrix and i should > > > >use #ifdef in the existing headers. > > > > > > Ok, can I then ask at least to minimize number of ifdefs to absolute > > > minimum? > > > > in principal no objection at all, one question though is what to do with > > comment based documentation attached to macros? e.g. > > > > #ifdef SOME_FOO > > /* some documentation */ > > #define some_macro > > #else > > #define some_macro > > #endif > > > > #ifdef SOME_FOO > > /* some documentation 2 */ > > #define some_macro2 > > #else > > #define some_macro2 > > #endif > > > > i can either duplicate the documentation for every define so it stays > > "attached" or i can only document the first expansion. let me know what > > you expect. > > > > so something like this? > > > > #ifdef SOME_FOO > > /* some documentation */ > > #define some_macro > > /* some documentation 2 */ > > #define some_macro2 > > #else > > #define some_macro > > #define some_macro2 > > #endif > > > > or should all documentation be duplicated? which can become a teadious > > redundancy for anyone maintaining it. keep in mind we might have to make > > an exception for rte_common.h because it seems doing this would be > > really ugly there. take a look let me know. > > My personal preference would be to keep one documentation block for both cases > (yes, I suppose it needs to be updated if required): > > /* some documentation, probably for both SOME_FOO on/off */ > #ifdef SOME_FOO > #define some_macro > #else > #define some_macro > #endif >
Or the third option of using a dummy for documentation purposes only. rte_memcpy() does this [1], although it is an inline function and not a macro. [1]: https://elixir.bootlin.com/dpdk/v23.03/source/lib/eal/include/generic/rte_memcpy.h#L90 No preferences here, just mentioning it! > > > > > > It is really hard to read an follow acode that is heavily ifdefed. Yes, and sometimes it is even harder reading code that is spread across multiple arch-depending files. It is a choice between the plague or cholera. But it is one of the unavoidable downsides to supporting many architectures and compilers, so we have to seek out the best compromises. > > > Let say above we probably don't need to re-define > > > rte_smp_rmb/rte_smp_wmb, as both are boiled down to > > > compiler_barrier(), which is already redefined.
