[dpdk-dev] [PATCH] scripts: add script for generating customised build config

[Bruce Richardson]

On Tue, Apr 19, 2016 at 02:30:08PM +0200, Thomas Monjalon wrote:
> Hi Bruce,
> 
> Thanks for pushing this idea.
> 
> 2016-04-19 11:27, Bruce Richardson:
> > This patch adds in the dpdk_config.py script file. It can be used
> > to generate custom build-time configurations for DPDK either manually on
> > the commandline or by calling it from other scripts. It takes as parameters
> > the base config template to use, and output directory to which the modified
> > configuration will be written. Other optional parameters are then taken
> > as y/n values which should be adjusted in the config file, and a special
> > -m flag is provided to override the default RTE_MACHINE setting in the
> > config template too.
> > 
> > Example, to create a build configuration with extra non-default PMDs
> > enabled, and the kernel modules disabled:
> > 
> >   ./scripts/dpdk_config.py -b $RTE_TARGET -o $RTE_TARGET PMD_PCAP=y \
> >      IGB_UIO=n KNI_KMOD=n MLX4_PMD=y MLX5_PMD=y SZEDATA2=y \
> >      NFP_PMD=y BNX2X_PMD=y
> 
> Would it be possible to use it without -b option to update a configuration?
> 
Interesting idea, but what would that really give us over manual editing? If
calling from a script, the user can just rebuild the config from scratch.

> Why not name it scripts/configure.py with a symlink ./configure in the
> top directory?

No objections here. It's just not really a "normal" configure script, instead
it's one designed to make it easy for me to generate directories with lots of
different build settings in them.
If we do want to make it to be "the" way to build DPDK, we can perhaps look at
additional enhancements to speed it up by working with the defconfigs directly,
as I'm not happy right now with the speed of the "make config" step.

On the other hand, I'm very happy with having it short and of limited scope.
Actual code only takes up about 50% of the file. :-)

> 
> Should we be able to list every options for a "-b defconfig"?
> 
Good idea, I think.
Under what conditions? Only if an invalid config is provided, or as part of
regular help text or otherwise?

> Would it be a good idea to manage dependencies checks in this script?
> 
I'd rather not do so here.
a) I don't think there are a huge number of dependencies to manage
b) I'd like to keep it from getting too long and complicated.

For 95% of use cases, being able to set a few y/n values on and off, and change
the machine type should suffice. I wasn't going for a 100% solution.

/Bruce