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 <hof...@lysator.liu.se
<mailto:hof...@lysator.liu.se>> wrote:
On 2024-04-30 15:52, Patrick Robb wrote:
>
>
> On Sun, Apr 28, 2024 at 3:46 AM Mattias Rönnblom
<hof...@lysator.liu.se <mailto:hof...@lysator.liu.se>
> <mailto:hof...@lysator.liu.se <mailto:hof...@lysator.liu.se>>> 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.
