[dpdk-dev] [PATCH 20.11 02/19] build: remove makefiles and mk directory

Bruce Richardson bruce.richardson at intel.com
Wed Aug 12 17:50:32 CEST 2020


On Fri, Aug 07, 2020 at 05:05:53PM +0200, Gaëtan Rivet wrote:
> On 07/08/20 19:31 +0530, Jerin Jacob wrote:
> > On Fri, Aug 7, 2020 at 7:04 PM Ferruh Yigit <ferruh.yigit at intel.com> wrote:
> > >
> > > On 8/7/2020 2:23 PM, Bruce Richardson wrote:
> > > > On Fri, Aug 07, 2020 at 06:49:47PM +0530, Jerin Jacob wrote:
> > > >> On Fri, Aug 7, 2020 at 6:15 PM Bruce Richardson
> > > >> <bruce.richardson at intel.com> wrote:
> > > >>>
> > > >>> On Fri, Aug 07, 2020 at 01:29:52PM +0100, Ciara Power wrote:
> > > >>>> It was decided [1] to no longer support Make in DPDK, this patch
> > > >>>> removes all Makefiles that do not make use of pkg-config, along with
> > > >>>> the mk directory previously used by make.
> > > >>>>
> > > >>>> [1] https://mails.dpdk.org/archives/dev/2020-April/162839.html
> > > >>>>
> > > >>>> Signed-off-by: Ciara Power <ciara.power at intel.com>
> > > >>>> ---
> > > >>>>  GNUmakefile                                   |  17 -
> > > >>>>  Makefile                                      |   4 -
> > > >>>
> > > >>> Open question from me:
> > > >>> Do we want to leave a dummy top-level makefile that prints instructions on
> > > >>> build with meson and ninja - or even runs a build using them if they are
> > > >>> installed?
> > > >>
> > > >> Maybe we can keep "make tags" as well in top-level Makefile.
> > > >
> > > > Is it better to point people directly to the script? My concern about
> > > > having a makefile is that it may confuse people as to how to build DPDK.
> > > > On the other side, there is a convenience aspect to having a makefile, so
> > > > I'm open to being convinced either way.
> > 
> > I was looking more of a convenience point of view.
> > Can we check how other meson based projects deal with similar problems?
> > 
> > > >
> > >
> > > A dummy Makefile to print instructions may be helpful for people missed the
> > > change, I am for having it.
> > >
> > > But I am dubious on extending it, like for tags, although I found it useful I
> > > think we should integrate it to meson instead.
> > 
> > I think, we can not integrate such stuff with meson. If we can with meson,
> > I agree we should take that path.
> 
> +1 to provide basic and short instructions to use meson when someone
> tries to use make.
> 
> On the other hand I think tag generation should not be part of the build
> system. The only dependency of build-tags.sh on make is for `make
> showconfigs`, they can probably be listed without using make.
> 
> The scripts seems standalone, why keep make to call it? The config
> target could be inferred if that's the issue?
> 
We may not actually need to do anything if we don't want to,
other than put some info in the docs.

https://mesonbuild.com/Release-notes-for-0-53-0.html#source-tags-targets

After running "meson build", "ninja -C build ctags" creates a tags file in
the root directory of my git tree, which vim picks up and uses without
problems. Admittedly this is from meson 0.53 onwards, but I'm not sure how
much extra effort we need to put in to support older versions for
developers. Anyone hacking the code is probably using up-to-date tools
anyway, one hopes!

Jerin, can you perhaps check to see if there are any problems with the
meson-generated tags file or if we are missing anything major compared to
the script-generated one? I would hope that it's pretty complete and that
we can also drop our ctags script in future too, and avoid maintaining it.

/Bruce


More information about the dev mailing list