On Thu, Jan 12, 2023 at 11:35:56AM +0000, Bruce Richardson wrote:
> Set the default C language standard to be used for DPDK builds to C99.
> This requires no actual code changes to build successfully.
>
> To ensure compatibility is kept for external apps using DPDK headers, we
> explicitly set the build parameters for the chkincs binary to the old
> minimum standard of "gnu89". [NOTE: DPDK code does not compile and has
> previously not compiled for pure c89 standard, so that stricter
> requirement need not be checked.] By adding this additional check, we
> can separately manage C standards used internally in DPDK builds and
> that required in the build flags for external apps using DPDK.
>
> Signed-off-by: Bruce Richardson <bruce.richard...@intel.com>
> ---
> buildtools/chkincs/meson.build | 1 +
> meson.build | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/buildtools/chkincs/meson.build b/buildtools/chkincs/meson.build
> index 378c2f19ef..322ac775ce 100644
> --- a/buildtools/chkincs/meson.build
> +++ b/buildtools/chkincs/meson.build
> @@ -30,6 +30,7 @@ executable('chkincs', sources,
> c_args: cflags,
> include_directories: includes,
> dependencies: deps,
> + override_options: 'c_std=gnu89',
> install: false)
>
> # run tests for c++ builds also
> diff --git a/meson.build b/meson.build
> index f91d652bc5..9a2963cc16 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -9,6 +9,7 @@ project('DPDK', 'C',
> license: 'BSD',
> default_options: [
> 'buildtype=release',
> + 'c_std=c99',
> 'default_library=static',
> 'warning_level=2',
> ],
subject to the atomics abstraction proposal where a meson option is
provided enable_stdatomics=true we'll want to be able to upgrade to
-std=c11 / c_std=c11 (as a minimum).
is there a meson mechanism that will let us evaluate that condition and
specify the higher required standard version in default_options or is it
a matter of some post project() or is this just done by adding
-std=c11 using add_project_arguments() after project()?
second, i think you will run into a build break with this change on some
platform / compiler combinations. somewhere we are using strerror_r where
the required posix versions are not specified in the translation unit
worked around by using c_std=gnu99 or by adding appropriate undef GNUC
etc.. in the place where strerror_r is used. (just something i noticed
when testing a similar change during prototyping i think ubuntu
22.04?)
going one step further i'd just ask that the default options be
"portable" i.e. they work with ! gcc and ! clang to help me with future
work. though i know that contradicts with my advice in the previous
paragraph, maybe we can set c_std=xxx subject to toolchain/platform?
Acked-by: Tyler Retzlaff <roret...@linux.microsoft.com>
