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 0D62E43F61; Wed, 1 May 2024 16:14:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7A620402A7; Wed, 1 May 2024 16:14:20 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id C78264021E for ; Wed, 1 May 2024 16:14:18 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AC6BFB3FD for ; Wed, 1 May 2024 16:14:17 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 8687EB4EF; Wed, 1 May 2024 16:14:17 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.3 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id E9F4BB47E; Wed, 1 May 2024 16:14:15 +0200 (CEST) Message-ID: Date: Wed, 1 May 2024 16:14:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Run unit tests with C++ too To: Ferruh Yigit , Patrick Robb Cc: "dev@dpdk.org" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "Richardson, Bruce" References: <4d5510d1-bdc6-43de-abbc-749eaa3c75a4@lysator.liu.se> <28dc7dc7-eb26-4405-9d80-9d8ec10f88b2@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 On 2024-05-01 11:10, Ferruh Yigit wrote: > On 4/30/2024 9:57 PM, Patrick Robb wrote: >> >> >> On Tue, Apr 30, 2024 at 4:13 PM Mattias Rönnblom > > wrote: >> >> On 2024-04-30 15:52, Patrick Robb wrote: >> > >> > >> > On Sun, Apr 28, 2024 at 3:46 AM Mattias Rönnblom >> >> > >> wrote: >> > >> >     It would be great if the unit test suite (app/test/*) was >> compiled (and >> >     run) using a C++ (C++11) compiler as well. At least, if such is >> >     available. >> > >> > >> > Sure, the UNH Lab can try this. >> > >> > >> >     With the current state of affairs, header file macros or >> functions are >> >     not verified to be functional (or even valid) C++. >> > >> >     "C is a subset of C++", which was never true, is becoming less and >> >     less so. >> > >> >     If all unit tests aren't valid C++, maybe one could start with >> an "opt >> >     in" model. >> > >> > >> > Okay, so basically run the fast-test suite, record all that don't >> pass, >> > submit a bugzilla ticket stating which unit tests are not valid on a >> > certain c++ compiler, then bring CI Testing online using the valid >> > subset of fast-tests. This should work. >> > >> >> Sounds good. >> >> Just to be clear: the above includes extending the DPDK build system to >> build the app/test/dpdk-test binary in two versions: one C and one C++, >> so that anyone can run the C++ tests locally as well. Correct? >> >> >> Okay, so now I am understanding this is not yet available. When I >> responded this morning I was figuring that c++ compiler support was >> available and I simply wasn't aware, and that we could quite easily set >> cc={some c++ compiler}, meson would pick it up, and we would be able to >> build DPDK and then run unit tests in this manner in CI testing. >> >> I didn't mean to suggest we would submit patches extending the build >> system to this end. That's probably a little out of scope for what we >> try to accomplish at the Community Lab. >> >> But if the aforementioned build system support is added, of course we >> are willing to add that as a build environment for unit tests and report >> those respective results. >> > > Does it have to be 'app/test/dpdk-test', why not build examples with C++? > The unit tests have the ability to test DPDK, which is exactly what we want to do here. Such testing isn't limited to "compiles yes/no", but to detect run-time (behavioral) issues, and properly report them. This is especially important for cases where there is code only exercised in C++ translation units (i.e., in #ifdef __cplusplus). > Examples source codes can be installed with existing build support. > Later we can build these examples with C++, this doesn't require any > update in build system. >