[dpdk-dev] [RFC] toolchain specific macro expansion

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

today rte_common.h defines common macros for use by dpdk and consuming
applications. most expansions are specific to the gcc toolchain.

example
// lib/eal/include/rte_common.h

/**
 * Hint never returning function
 */
#define __rte_noreturn __attribute__((noreturn))

there is an anticipated need rte_common.h to expose alternate
expansions for non-gcc toolchains in the future and would like
comments on how to achieve this in an agreeable manner.


option 1 add conditional compilation directly to rte_common.h

example
// lib/eal/include/rte_common.h

/**
 * Hint never returning function
 */
#ifdef RTE_TOOLCHAIN_GCC
#define __rte_noreturn __attribute__((noreturn))
#endif

#ifdef RTE_TOOLCHAIN_FOO
#define __rte_noreturn __foo_expansion_for_noreturn
#endif

represents the simplest approach technically but may be tedious to
maintain due to the number of macros and number of conditional
expansions per macro.


option 2 add toolchain specific files (follow existing platform/os
         includes pattern)

example:
// lib/eal/gcc/rte_toolchain_common.h
#define __rte_noreturn __attribute__((noreturn))

// lib/eal/include/rte_common.h
#include <rte_toolchain_common.h>

// meson.build (illustrative change)
host_toolchain = cc.get_id() # e.g. gcc

global_inc = include_directories('.', 'config',
    'lib/eal/include',
    'lib/eal/@0@/include'.format(host_machine.system()),
    'lib/eal/@0@/include'.format(arch_subdir),
    'lib/eal/@0@/include'.format(host_toolchain),
)

results in the introduction of more files that need to be
published/installed for applications but separate files per
implementation allow for easier maintainability.


we are interested in hearing about alternatives not listed here but in
the absence of other options we would propose to submit a patch
following option 2.

comments and alternatives welcome.

thanks