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

[Jerin Jacob]

On Wed, Aug 12, 2020 at 9:20 PM Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> 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.

I just checked rte_pause definition for x86 build, It is picking up
x86, arm, ppc definition also.
so meson doesn't have that kind of tag level support like the script.
But I am OK to drop the script, if that's the path we are planning to take.
No strong opinion.



>
> /Bruce