[dpdk-dev] [PATCHv4 4/5] Makefile: Do post processing on objects that register a driver

Neil Horman nhorman at tuxdriver.com
Wed May 25 22:16:10 CEST 2016


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



More information about the dev mailing list