[dpdk-dev] [PATCH 01/17] build: add initial infrastructure for meson & ninja builds

[Bruce Richardson]

On Mon, Sep 04, 2017 at 02:51:01PM +0100, Bruce Richardson wrote:
> On Mon, Sep 04, 2017 at 02:36:42PM +0100, Van Haaren, Harry wrote:
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
> > > Richardson Sent: Friday, September 1, 2017 11:04 AM To:
> > > dev at dpdk.org Cc: Richardson, Bruce <bruce.richardson at intel.com>
> > > Subject: [dpdk-dev] [PATCH 01/17] build: add initial
> > > infrastructure for meson & ninja builds
> > > 
> > > To build with meson and ninja, we need some initial infrastructure
> > > in place. The build files for meson always need to be called
> > > "meson.build", and options get placed in meson_options.txt
> > > 
> > > This commit adds a top-level meson.build file, which sets up the
> > > global variables for tracking drivers, libraries, etc., and then
> > > includes other build files, before finishing by writing the global
> > > build configuration header file and a DPDK pkgconfig file at the
> > > end, using some of those same globals.
> > > 
> > > From the top level build file, the only include file thus far is
> > > for the config folder, which does some other setup of global
> > > configuration parameters, including pulling in architecture
> > > specific parameters from an architectural subdirectory. A number
> > > of configuration build options are provided for the project to
> > > tune a number of global variables which will be used later e.g.
> > > max numa nodes, max cores, etc. These settings all make their way
> > > to the global build config header "rte_build_config.h". There is
> > > also a file "rte_config.h", which includes "rte_build_config.h",
> > > and this file is meant to hold other build-time values which are
> > > present in our current static build configuration but are not
> > > normally meant for user-configuration. Ideally, over time, the
> > > values placed here should be moved to the individual libraries or
> > > drivers which want those values.
> > > 
> > > Signed-off-by: Bruce Richardson <bruce.richardson at intel.com>
> > 
> > Comments inline below;
> > 
> > <snip>
> > 
> > > diff --git a/config/meson.build b/config/meson.build
> > <snip>
> > > +# disable any unwanted warnings +unwanted_warnings = [ +
> > > '-Wno-address-of-packed-member', +	'-Wno-format-truncation'
> > > +] +foreach arg: unwanted_warnings +	if cc.has_argument(arg)
> > > +		add_project_arguments(arg, language: 'c') +	endif
> > > +endforeach
> > 
> > I can't fault the code here, or Meson, just noting that the
> > disabling of these warnings causes prints on GCC 4.8.5 and GCC
> > 5.4.0, GCC 7 only prints on -Wno-address-of-packed-member. Clang
> > handles it correctly - and no out-of-the-ordinary prints occur. No
> > code changes required here.
> >
> 
> Strange. Just tested with gcc 4.8.5 and gcc 5.4, and everything worked
> as expected, no errors or warnings.
> 
Dug into the invalid flag warnings a bit more and found a number of
items in the root cause.

First is that gcc only complains about invalid -Wno-* parameters in the
case where there is another error or warning being printed. This
explains why the warnings are only seen for some files, rather than
others.
Second is that, because of this meson, is not correctly identifying the
relevant flags as unsupported by the compiler. I'm looking to upstream
to meson a fix for this.
Third is that there are more warnings that need to be disabled for some
files when compiled with gcc 5.4. So long as there are no other problems
with the code, gcc will never print the errors about the invalid warning
disable flags.

So, for V2 of this, I hope to fix point 3.

/Bruce