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 11509A0526; Tue, 10 Nov 2020 14:37:14 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D3632F90; Tue, 10 Nov 2020 14:37:11 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 91D2DF64 for ; Tue, 10 Nov 2020 14:37:08 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 14B3CD37; Tue, 10 Nov 2020 08:37:06 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 10 Nov 2020 08:37:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= WW3QuKaKE80emrnYtvNAnz56pcaAj25T/2UDXepM/vY=; b=KigdJRxz7SNIx3EI LaDYXFHSfIRA7z9vjZWJcgsvn/lhiwyYfbvnmPB7Rocm6Vptqvf0zBQrNOERTQey 7FTdbZenpV6d3lZDt/mmkp/9bOvFUKkKt5rdT4gpyFQKO/LAQ5jm8a0oDVeFgr0g uEjph9KMkUlg5XjWEJliaL1iEq4J0ehnoPRoCWmd122WAtboBv8s7dWtZaUh3R77 LxCutU6nCRG3DeAuBhYzogHNayR/QzkaN3IicB5P17yEed4gzQpw8e5R0bhc+M1M HCB4n5244RjDOqc0dcBU2228DnmrDsqpAWE25p2XiMsQQukn0ac3NiSQDYr78Xvg Nxn2NA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=WW3QuKaKE80emrnYtvNAnz56pcaAj25T/2UDXepM/ vY=; b=Oq5MJDuYpyqFF2M3+sWR2vipZ/C7xnYBTSYxWsUwG+4/jooXeY3scDuyJ +4FYc9K4xZqL4dSo/LwQHlfta+H6w7t6EDdQ5xyZROfvxRw3+S5oIWxoUvov2jBu pYsnJFkFmYYFH9tyiChvOF5x15vlg3wDwdpSFWgTFOfP8yn1o3oAZUqh4568hx1i UNmb325QcDmA3bQX+NPa6glD5AL6qtJQXLTOAPeEvSPY9Xt1q0Kdlsyu99asPNsJ rcisIsw8yR5j/IztKy1OocSnPje1oIYSvra6yZjzcH+sdTq8SLxOUNHw0aO4yfme ObbtuKRaf1FFgvYKXSKufgu7GKwLw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddujedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id E515D3280059; Tue, 10 Nov 2020 08:37:03 -0500 (EST) From: Thomas Monjalon To: David Marchand , Bruce Richardson Cc: "Jiang, Cheng1" , Maxime Coquelin , "Xia, Chenbo" , dev , "Fu, Patrick" , "Yang, YvonneX" , "Yigit, Ferruh" , "Hu, Jiayu" Date: Tue, 10 Nov 2020 14:37:02 +0100 Message-ID: <5954084.PnIyprfhLy@thomas> In-Reply-To: <20201110111930.GC1641@bricha3-MOBL.ger.corp.intel.com> References: <20200910064351.35513-1-Cheng1.jiang@intel.com> <20201110111930.GC1641@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 10/11/2020 12:19, Bruce Richardson: > 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. The external compilation is part of the example, yes. > * 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. In the past we had a Makefile which builds all examples. If you want, it can even been called at the end of meson DPDK compilation. > 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. I don't understand this point: ninja -C build && make -C examples/myexample > * Therefore, while it looks like the more logical part to drop is indeed > the meson support for the examples, Yes, building the examples from the inside build system is strange, and hide issues. > 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. We don't have to use meson at all. > * 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. Hand-crafted Makefile is enough. They may be improved. If we feel it is too hard, we can use another build system in examples, like cmake. > So overall my assessment is that it needs a bit of investigation and > prototyping to see what we can come up with. I think testing external build + removing build from internal meson would be a good start to ensure quality of examples maintenance. > 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. We can. We just have to add all examples in test-meson-builds.sh. > 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? No the concern is to have all contributors work on the same single build path. > 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? When there is a failure, authors receive an email, and maintainers can see a red flag. I think it's OK. The only issue was that this build path was not tested. I think David is going to fix it by compiling all possible examples with external make build from test-meson-builds.sh.