[dpdk-dev] [PATCH v10 0/4] add async data path in vhost sample

Bruce Richardson bruce.richardson at intel.com
Tue Nov 10 12:19:30 CET 2020


On Tue, Nov 10, 2020 at 09:17:36AM +0100, David Marchand wrote:
> On Tue, Nov 10, 2020 at 4:02 AM Jiang, Cheng1 <cheng1.jiang at intel.com> wrote:
> > > - This series breaks external compilation, as the external Makefile was not
> > > updated.
> > >
> >
> > I'm not sure I understand what you mean by external Makefile, because as far as I know, makefile has been deprecated.
> 
> make support is dropped for dpdk compilation itself.
> 
> For the examples, the users will use make to compile them, as this is
> the only way provided to users *out of* dpdk.
> But the examples are compiled too via meson when compiling dpdk itself
> if you pass -Dexamples= options.
> 
> 
> Bruce,
> 
> I want to avoid more misses like this one.
> 
> If we want to keep the examples compilation in meson, we need a
> consistent framework to compile in both cases.
> Right now, we don't export meson for examples, and it makes no sense
> in their current form.
> It seems simpler to me to only maintain make support, and meson can
> still call make for each example.
> 
> Another solution is to rely only on test-meson-builds.sh, but then it
> ends up on the maintainer shoulders, so I prefer the solution above.
> 
> Other ideas?
> 

Hi David,

I've been thinking a bit about this since I got your email, but inspiration
for new ideas has yet to strike me.

While I can see the downside of having both make and meson build files for
the examples, I'm loath to see one of them dropped. Here is my current
thinking on it:

* We obviously need to keep the basic makefiles so as to make it easy for
  end-users to compile up and use the examples separate from DPDK itself.
  The makefiles serve as good examples as to how to pull the DPDK info from
  pkg-config.

* On the other hand, being able to build the examples as part of a regular
  meson build is a big advantage over having to build them separately, and
  allows errors with examples to be caught quicker. It's also useful for
  those of us working on specific components with associated sample apps to
  have just that one app built constantly as we work.

* Therefore, while it looks like the more logical part to drop is indeed
  the meson support for the examples, we may struggle to implement clean
  building of the examples from meson using make, at least until meson 0.54
  becomes our standard. Before that version, we don't have a
  "meson-uninstalled" folder with build-time package-config file to use as
  source of build flags for each example.

* One final idea I had and investigated in the past was whether we could at
  build or install time auto-generate the Makefile for each example from
  the meson.build file. Unfortunately, nothing came of that idea the first
  time I tried it, but it might still be worth looking at. Even if it works
  for 80-90% of cases, it means that we have a much smaller subset of
  examples where we need to test independently the make and meson builds.

So overall my assessment is that it needs a bit of investigation and
prototyping to see what we can come up with.

On a semi-related note, it's perhaps a bigger problem that we cannot rely
on test-meson-builds and CI infrastructure to prevent issues like this.
Surely this is what CI is there for - to help reduce the workload for
maintainers. The fact that we are considering removing the meson build of
examples because we cannot rely on CI is surely more worthy of a solution
than trying to find a way to build examples with make from within meson?

Perhaps we need to see about stricter measures from CI failure, e.g.
anything failing travis build automatically gets marked as changes
requested in patchwork, and the author gets an email informing them of
such?

Regards,
/Bruce


More information about the dev mailing list