From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id F2D161B119 for ; Tue, 29 Jan 2019 12:52:33 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2019 03:52:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,537,1539673200"; d="scan'208";a="118327228" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.54]) by fmsmga007.fm.intel.com with SMTP; 29 Jan 2019 03:52:30 -0800 Received: by (sSMTP sendmail emulation); Tue, 29 Jan 2019 11:52:29 +0000 Date: Tue, 29 Jan 2019 11:52:29 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org Message-ID: <20190129115229.GA80176@bricha3-MOBL.ger.corp.intel.com> References: <20190125202642.66559-1-bruce.richardson@intel.com> <20190125203019.GA57044@bricha3-MOBL.ger.corp.intel.com> <2309208.nfQRyMXgnH@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2309208.nfQRyMXgnH@xps> User-Agent: Mutt/1.11.2 (2019-01-07) Subject: Re: [dpdk-dev] [PATCH 0/4] RFC: consolidate testing apps to app dir 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: , X-List-Received-Date: Tue, 29 Jan 2019 11:52:34 -0000 On Tue, Jan 29, 2019 at 12:40:37PM +0100, Thomas Monjalon wrote: > 25/01/2019 21:30, Bruce Richardson: > > On Fri, Jan 25, 2019 at 08:26:38PM +0000, Bruce Richardson wrote: > > > The apps for testing are split between the "test" and "app" directories, > > > with a not-very-clear distinction between the two (at least to my mind). > > > > > > Given how the apps are being built, the easiest path to having > > > cmdline_test, test-acl and test-pipeline build using meson is to > > > consolidate all these apps back into the app folder and use the logic > > > there. The bpf folder doesn't contain an actual application, but > > > rather example bpf code which can be loaded into testpmd. That is > > > possibly best moved to the examples folder, but I'm open to feedback > > > on the best place for it. > > > > > > With these changes, the "test" folder then becomes the location for > > > unit tests only. > > > > > > > > > Bruce Richardson (4): > > > test/cmdline_test: move to app directory > > > test/test-acl: move to app directory > > > test/test-pipeline: move to app directory > > > test/bpf: move to examples folder > > > > > > > Although these patches are for 19.05, I'm sending them now for some early > > review, as I think we need a deprecation notice for this change in 19.02 if > > these changes are acceptable to people. > > We don't need a deprecation notice, as it is an internal change > without any impact for the users. > Yes, good point. With the make build system these test apps end up in the app folder anyway. With meson, they aren't yet built, so either way it isn't a user-visible change. > > Therefore, please review and let me know any issues people see with this > > change. > > We should move all test apps into the same directory. > Is there any benefit of keeping unit tests separate? > It looks more logic to move everything in test/ > but it would make the git history of testpmd more complex. > The other choice is to move all tests in app/. > I'd prefer to keep things in app, for legacy reasons more than anything else. Not sure about moving the unit tests there too - I sort of like having them in a separate test directory. However, if others generally prefer that they too get consolidated into app, I won't complain! :-) If we do end up moving the tests, another thing to consider is whether we want to split them up by topic or suite. There are now a lot of C files in the test folder, which suggests to me we need to split things a little. > The other split to discuss is between app/ and usertools/. > We could move user-oriented apps to usertools. > pdump and proc-info fall into this basket because they > can be used for debugging purpose. > Yes. However, is this better handled via the installation rather than the build? Even if the source code is moved to the usertools directory, the actual binaries are going to be placed in the build folder, separate from the scripts anyway. I'd suggest leaving them as they are, though perhaps putting in a symlink to them from the usertools folder to make them easier to find. /Bruce