From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 892F5A04DA; Wed, 12 Aug 2020 17:50:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6BF591C0AD; Wed, 12 Aug 2020 17:50:45 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 53D1A1C0B3 for ; Wed, 12 Aug 2020 17:50:40 +0200 (CEST) IronPort-SDR: WUsMw51la8HMveTQg0BHvM9bMtvNM7pHntMHi3MLI67qcCfCsOV/cmf+0PhkkCu8S/D3EMbNVv JWbB/emlCrzQ== X-IronPort-AV: E=McAfee;i="6000,8403,9711"; a="153202228" X-IronPort-AV: E=Sophos;i="5.76,304,1592895600"; d="scan'208";a="153202228" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Aug 2020 08:50:39 -0700 IronPort-SDR: dEaRjF3bKHGoToOgl2tfKd74ZfUaUqH/3hkLr3dXO3rw+afvP+3qSyRdGa4xLbaHlLZY3Ww7n8 SjkwVCcaRMgg== X-IronPort-AV: E=Sophos;i="5.76,304,1592895600"; d="scan'208";a="318149522" Received: from bricha3-mobl.ger.corp.intel.com ([10.255.202.43]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 12 Aug 2020 08:50:37 -0700 Date: Wed, 12 Aug 2020 16:50:32 +0100 From: Bruce Richardson To: =?iso-8859-1?Q?Ga=EBtan?= Rivet Cc: Jerin Jacob , Ferruh Yigit , Ciara Power , dpdk-dev , Thomas Monjalon Message-ID: <20200812155032.GH312@bricha3-MOBL.ger.corp.intel.com> References: <20200807123009.21266-1-ciara.power@intel.com> <20200807123009.21266-3-ciara.power@intel.com> <20200807124536.GA302@bricha3-MOBL.ger.corp.intel.com> <20200807132343.GA306@bricha3-MOBL.ger.corp.intel.com> <20200807150553.ujvph5i5jzuu77ok@u256.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200807150553.ujvph5i5jzuu77ok@u256.net> Subject: Re: [dpdk-dev] [PATCH 20.11 02/19] build: remove makefiles and mk directory X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 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 > > > >> 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 > > > >>>> --- > > > >>>> 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