DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com,
	mb@smartsharesystems.com
Subject: Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds
Date: Wed, 22 Feb 2023 10:53:44 -0800	[thread overview]
Message-ID: <20230222185344.GB2702@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <20230112113556.47485-1-bruce.richardson@intel.com>

On Thu, Jan 12, 2023 at 11:35:55AM +0000, Bruce Richardson wrote:
> Traditionally, DPDK has never specified a minimum C standard used either
> in DPDK builds or for applications using DPDK. Following discussion
> on-list about C standards, this RFC attempts to start the process of
> codifying what our standards expectations are. No code changes are made
> by this RFC, instead only the build parameters are changed to explicitly
> specify:
> 
> * C99 standard is used to build DPDK itself. This is supported by all
>   supported compiler versions of GCC and Clang.
> * The headers are checked for compatibility with gcc89 standard, which
>   was the default standard used by the oldest supported version of GCC.
>   DPDK headers do not build with the official C89 standard, and, to the
>   best of my knowledge, have never done so.

subject to the technical board meeting 2023/02/22 in relation to atomics
and adoption of C11 starting in 23.11 does anything stop us from
conditionally enabling/defaulting -std=C11 for all platforms immediately
except for RHEL/CentOS 7?

so long as we don't actually start using C11 features we should be able
to do this? or would we be worried that C11 feature use would creep in?

just curious.

> 
> Bruce Richardson (1):
>   build: increase minimum C standard for DPDK builds
> 
>  buildtools/chkincs/meson.build | 1 +
>  meson.build                    | 1 +
>  2 files changed, 2 insertions(+)
> 
> --
> 2.37.2

  parent reply	other threads:[~2023-02-22 18:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 11:35 Bruce Richardson
2023-01-12 11:35 ` [RFC PATCH 1/1] build: increase minimum C standard " Bruce Richardson
2023-01-12 12:42   ` Morten Brørup
2023-01-12 12:47     ` Bruce Richardson
2023-01-12 15:06       ` Morten Brørup
2023-01-12 17:04   ` Tyler Retzlaff
2023-02-03 14:09 ` [RFC PATCH 0/1] Specify C-standard requirement " Ben Magistro
2023-02-03 15:09   ` Bruce Richardson
2023-02-03 16:45     ` Ben Magistro
2023-02-03 18:00       ` Bruce Richardson
2023-02-10 14:52         ` Ben Magistro
2023-02-10 23:39           ` Tyler Retzlaff
2023-02-22 18:53 ` Tyler Retzlaff [this message]
2023-02-23  9:44   ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230222185344.GB2702@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
    --to=roretzla@linux.microsoft.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).