[dpdk-dev] [PATCH v5] net/mlx: add meson build support

Shahaf Shuler shahafs at mellanox.com
Thu Sep 13 12:12:18 CEST 2018


Hi Bruce,

Sorry for the late reply. Holiday time in Israel. 

Thursday, September 13, 2018 12:22 PM, Bruce Richardson:
> Subject: Re: [dpdk-dev] [PATCH v5] net/mlx: add meson build support
> 
> On Fri, Sep 07, 2018 at 11:34:29AM +0100, Bruce Richardson wrote:
> > On Wed, Sep 05, 2018 at 02:47:46PM +0300, Shahaf Shuler wrote:
> > > From: Nelio Laranjeiro <nelio.laranjeiro at 6wind.com>

[...]

> > couple of minor points:
> > * These new additions use tab rather than space for indent. The standard
> >   with meson I think is normally spaces, but I (inadvertently) added all
> >   other DPDK meson.build files with tabs, so for consistency I think it
> >   would be good if the whole file used tabs i.e. change all the other lines
> >   apart from your new ones in v5.

OK, all indentation will be with tab.  

> >
> > * is the "rm" command really necessary? I would expect the
> configure_file()
> >   function to just do the right thing here when replacing the file.

Yep it is not needed. Also from meson sources:
        output = kwargs['output']                                                                                
        ofile_rpath = os.path.join(self.subdir, output)                                                          
        if not isinstance(output, str):                                                                          
            raise InterpreterException('Output file name must be a string')                                      
        if ofile_rpath in self.configure_file_outputs:                                                           
            mesonbuildfile = os.path.join(self.subdir, 'meson.build')                                            
            current_call = "{}:{}".format(mesonbuildfile, self.current_lineno)                                   
            first_call = "{}:{}".format(mesonbuildfile, self.configure_file_outputs[ofile_rpath])                
            mlog.warning('Output file', mlog.bold(ofile_rpath, True), 'for configure_file() at', current_call, 'o
verwrites configure_file() output at', first_call)                                                               

> >
> > * Would you consider splitting the args array into two arrays, one for the
> >   "type" values and another for the enum/define ones? This would mean
> >   having two loops, but the loops themselves would be clearer and shorter -
> >   as would the arrays.  Especially since according to
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmes
> onbuild.com%2FConfiguration.html&data=02%7C01%7Cshahafs%40mell
> anox.com%7C38f62333815c48eaea6e08d6195a908a%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C636724274091500993&sdata=fZvTg16D8K
> TsE7Q0DWsS9hiNnB%2BhHPuHi%2FFC7wrk8x8%3D&reserved=0
> >   a boolean false converts to an "undef", rather than a 0/1 value.
> >   For example:
> >
> > 	foreach arg:has_sym_args
> > 		config.set(arg[0], cc.has_header_symbol(arg[1], arg[3]))
> > 	endforeach
> >

Done.

> > * Very minor suggestion: is it neater to use "args: '-include ' + arg[1]",
> >   instead of using prefix with the #include syntax? [Assuming the former
> >   works]

I don't understand the benefit with this change. Is there? 

> >
> 
> Any plans for a new version of this? If so, can I also suggest splitting the patch
> into two, one for mlx4 and the other for mlx5.

No problem to split.

Another change in plans: 
diff --git a/meson_options.txt b/meson_options.txt
index 484f3e2601..444a380d97 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -1,7 +1,7 @@
 option('allow_invalid_socket_id', type: 'boolean', value: false,
        description: 'allow out-of-range NUMA socket id\'s for platforms that don\'t report the value correctly')
 option('enable_driver_mlx_glue', type: 'boolean', value: false,
-       description: 'Enable glue library for Mellanox ConnectX-3/4/5 NIC PMD')
+       description: 'Enable glue library for Mellanox PMDs')
 option('enable_kmods', type: 'boolean', value: true,
        description: 'build kernel modules')
 option('examples', type: 'string', value: '',

I don't see the need to constantly update with each device being added.  

> 
> Regards,
> /Bruce


More information about the dev mailing list