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

Neil Horman nhorman at tuxdriver.com
Wed May 25 21:43:41 CEST 2016


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



More information about the dev mailing list