From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 8EDC358CF for ; Wed, 25 May 2016 22:04:15 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id n129so75669682wmn.1 for ; Wed, 25 May 2016 13:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=NIv5F0ZTDoAUtnzDxNIMw+T3BDPBy79dlml7OM+Fsy0=; b=T73LoLLLBZv7EKR/gsevweE/rAcHaga3UIm45S5VElAGMnpgpr04ndXPl4ps707CXA H3twNnUsGUKMeqfGT1+nYE3aue5MIK/GtbCVE+ntsW+EYTtANFLeLII2mYhPyAPYPfW3 UcKZ0/h1wHyNgu7y4aCyVYOybQOa1iI9Adzq3UTDTaHC9cd69h6C0B6tYB2LOgWjUJ/L peRDzgbpj4LX+plPPgFII5X4GeeBLj3mtOhhf1k+w5MLzk4bhf/ASe87YM/0a5X25KvJ XhwQP+CofAEXUU+LcMo2flRc3/6n4jH1nrUaQAtJq4cGv0Ca8tZ2qGXdmjAx2CPTESZK oGzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=NIv5F0ZTDoAUtnzDxNIMw+T3BDPBy79dlml7OM+Fsy0=; b=Va9M3FNcPBNiHw0thUn2AwUijxpWEn1Av95aKWfJXtDQgSAY1++dVZgpi8veiYsWu+ FLjvwjTLGMVb0XPhA7mR/UurJ+tUv17gxk9E5SrR7mdtCerQPhLA2OHdtklxcFsTm/57 o8/515rOnpSNsoM/70Rn2a+iDSTqrT6uZqA6/2ddWFiqL+6C3Ug1V8fE2u1G/PEOahwZ oxYsApKVaMlmGQLxOIlTYad2VcbmxW895iHQ6YE87o8gK8+/6oIOzD30QkFuj8dEZBOQ VsbGmp4GTdtTCzObtw6iEOE7vJ1BsHS80jnhruaHcIpDuXWy+sgOWQnNluwxAQoLLXXr HIUA== X-Gm-Message-State: ALyK8tLsy8y6QL8PgttPqXuJCtx2yQeYzRfv89O/gOgn9lFPkHUZfhvI8DeSYMKq+93KcybC X-Received: by 10.28.63.5 with SMTP id m5mr5618217wma.24.1464206655275; Wed, 25 May 2016 13:04:15 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id i190sm26524818wmf.10.2016.05.25.13.04.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 13:04:14 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Panu Matilainen Date: Wed, 25 May 2016 22:04:11 +0200 Message-ID: <1532404.q0ENaP47EE@xps13> User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160525194341.GG14322@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <4086744.quTHnGcz6Y@xps13> <20160525194341.GG14322@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:04:15 -0000 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.