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 7C6A75A03 for ; Wed, 25 May 2016 22:16:21 +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 1b5fDz-0000qz-SN; Wed, 25 May 2016 16:16:17 -0400 Date: Wed, 25 May 2016 16:16:10 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Panu Matilainen Message-ID: <20160525201610.GI14322@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <4086744.quTHnGcz6Y@xps13> <20160525194341.GG14322@hmsreliant.think-freely.org> <1532404.q0ENaP47EE@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1532404.q0ENaP47EE@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 20:16:21 -0000 On Wed, May 25, 2016 at 10:04:11PM +0200, Thomas Monjalon wrote: > 2016-05-25 15:43, Neil Horman: > > 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? > > pmd/PMDINFO// > > > > > > 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 > > OK, no strong opinion here. > If you feel comfortable with multi-lines "sh -c" and escaping, up to you. > If I discover something wrong in this part and needs to do some maintenance > work, I'll probably think differently. > You're welcome to assign the bug to me :) Neil