From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id AAE532BA9 for ; Wed, 25 May 2016 21:43:52 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b5eiZ-0000f8-Hl; Wed, 25 May 2016 15:43:49 -0400 Date: Wed, 25 May 2016 15:43:41 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Panu Matilainen Message-ID: <20160525194341.GG14322@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1591100.WzDkHNrJoU@xps13> <20160525174051.GD14322@hmsreliant.think-freely.org> <4086744.quTHnGcz6Y@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4086744.quTHnGcz6Y@xps13> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCHv4 4/5] Makefile: Do post processing on objects that register a driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:43:52 -0000 On Wed, May 25, 2016 at 08:56:25PM +0200, Thomas Monjalon wrote: > 2016-05-25 13:40, Neil Horman: > > On Wed, May 25, 2016 at 07:08:19PM +0200, Thomas Monjalon wrote: > > > 2016-05-24 15:41, Neil Horman: > > > > + echo MODGEN $@; \ > > > > + OBJF=`readlink -f $@`; \ > > > > + ${RTE_OUTPUT}/buildtools/pmdinfogen \$$OBJF \$$OBJF.mod.c; \ > > > > > > Maybe .pmd.c would be more appropriate than .mod.c? > > fine > > > What means mod/MODGEN/MODBUILD? > > GENerate Module information & BUILD module information. > > I think "module" is not appropriate here. > This is starting to feel very much like bikeshedding. What do you think would be more appropriate here? > > > It deserves to be in a shell script, at least to ease testing. > > What do you mean by "it" and why would it be easier to test in a shell script? > > "it" is mostly this whole patch. > With a shell script, we can test the behaviour on one file easily. > Maybe I'm wrong, but I don't like having too much lines in a Makefile rule. > We probably need more opinions. > That makes no sense to me. Any such script would need to receive two arguments: 1) The path to a C file for a pmd 2) The path to the corresponding object file for that pmd Running any such script is then usless unles its predecated on first building all the object files in the pmd. And if you want to run something by hand on the object files, it seems pretty straightforward to do so, just run: build/builttools/pmdinfogen /path/to/pmd/object/file The rest of that code is really just a test to avoid having to run pmdinfo gen on any files other than the ones that contain the PMD_REGISTER_DRIVER macro Neil