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 4A18DA0526; Tue, 10 Nov 2020 12:19:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 14A19F90; Tue, 10 Nov 2020 12:19:41 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 591E1F64 for ; Tue, 10 Nov 2020 12:19:39 +0100 (CET) IronPort-SDR: bl6HW33sYY5a6wLxcltOKZgCVvE2SMfN5Td4CMNVAYqabRH56Ryty0yGiBNM20+NoXxFHHXAWZ UcKQlFz03eww== X-IronPort-AV: E=McAfee;i="6000,8403,9800"; a="149805887" X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="149805887" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2020 03:19:36 -0800 IronPort-SDR: q8UdwYiU54sYOcjOxlhEfQOLQKfj2znX4nShSDRPfk2ZjhoVcBXsR3YsQ6yxBPrAajHELdoCd7 rpiytej1yX+w== X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="531171898" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.241.186]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 10 Nov 2020 03:19:34 -0800 Date: Tue, 10 Nov 2020 11:19:30 +0000 From: Bruce Richardson To: David Marchand Cc: "Jiang, Cheng1" , Maxime Coquelin , "Xia, Chenbo" , dev , "Fu, Patrick" , "Yang, YvonneX" , Thomas Monjalon , "Yigit, Ferruh" , "Hu, Jiayu" Message-ID: <20201110111930.GC1641@bricha3-MOBL.ger.corp.intel.com> References: <20200910064351.35513-1-Cheng1.jiang@intel.com> <20201022085909.112403-1-Cheng1.jiang@intel.com> <893690b2-0605-1445-fc31-3186a2ab21d7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v10 0/4] add async data path in vhost sample 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 Tue, Nov 10, 2020 at 09:17:36AM +0100, David Marchand wrote: > On Tue, Nov 10, 2020 at 4:02 AM Jiang, Cheng1 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