From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5074143064; Mon, 14 Aug 2023 20:28:22 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E957A432B2; Mon, 14 Aug 2023 20:28:21 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id E191C432A7 for ; Mon, 14 Aug 2023 20:28:20 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id ED61D206BD; Mon, 14 Aug 2023 20:28:18 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v4 4/4] build: enable MSVC specific compiler options Date: Mon, 14 Aug 2023 20:28:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87AFB@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v4 4/4] build: enable MSVC specific compiler options Thread-Index: AdnOzwH05kp8zZX9QJi7Lc3vCOindwACCD8A References: <1674674707-3094-1-git-send-email-roretzla@linux.microsoft.com> <1691778287-15746-1-git-send-email-roretzla@linux.microsoft.com> <1691778287-15746-5-git-send-email-roretzla@linux.microsoft.com> <20230814161053.GA10752@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "Tyler Retzlaff" Cc: , "Konstantin Ananyev" , , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Monday, 14 August 2023 18.47 >=20 > On Mon, Aug 14, 2023 at 09:10:53AM -0700, Tyler Retzlaff wrote: > > On Mon, Aug 14, 2023 at 09:30:20AM +0100, Bruce Richardson wrote: > > > On Fri, Aug 11, 2023 at 11:24:47AM -0700, Tyler Retzlaff wrote: > > > > * Enable optional use of C11 atomics support. * Enable use of = C23 > > > > typeof operator. * Explicitly force intrinsics when building = with > > > > MSVC. * Disable MSVC C runtime checks. > > > > > > > > Signed-off-by: Tyler Retzlaff > > > > > > Acked-by: Bruce Richardson > > > > > > If there is going to be a lot of this type of special handling for > > > MSVC, we could look to add a separate config/msvc (and config/gcc- > like) > > > directory with separate meson.build files for the different > toolchains. > > > Might help centralize all such definitions in one place rather = than > > > having conditionals everywhere. Please think twice before splitting into per-toolchain files! You must = consider the ratio of differences vs. similarities. For reference, consider the EAL, which has per-arch subdirectories = basically containing the same files, whereof many contain nearly similar = content for the different architectures. And much of it is not even arch-specific at all, but plain C. There is way too much copy-paste in this design pattern. Although a "default fallback" implementation could alleviate some of = this, minor arch-specific deviations in a function would still require a = full copy-paste of the function's remaining code. In my opinion, a lot of this would be better having in unified files = with #ifdefs where required by one or more architectures. It would also = allow arch A and arch B to share one implementation, while arch C and = arch D share another, and arch E has its own. The EAL might be a really bad comparison here, but it's a good example = of a differences/similarities ratio moving in an unfavorable direction = for the design pattern. I also hope it serves as an example of how not to do it. That being said, I admit that it could probably be done right. In this = case, it's a mostly matter of taste if you prefer keeping the = differences together in one file, or having the differences spread out = at the locations where they have their actual effect. > > > > i think that would probably be a good idea. it would untangle the > > toolchain detail from the flow of the build files. > > > > i don't propose introducing it in this series but when this is = merged > i > > would like to reach out and get your thoughts on how to properly set > up a > > config/toolchain-xxx. in addition to the compiler flags and > definitions > > below it would be good to suppress (for now) warnings until i have = an > > opportunity to evaluate and address the code raising them. > > > Agree on not requiring it for this set. I'm not exactly sure how to > split > up the toolchain files, especially given that gcc and clang (and other > llvm-based compilers like icx) are so very, very similar in what we = have > to > do for them. It would be very wasteful to have individual toolchain > files > for each one, duplicating lots of settings. That's why my initial > suggestion was for msvc and "gcc-like" compilers. Any suggestions for = a > better name for the latter, welcome! :-)