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

[Neil Horman]

On Thu, Sep 07, 2017 at 04:47:00PM +0000, Wiles, Keith wrote:
> 
> > On Sep 7, 2017, at 9:21 AM, Neil Horman <nhorman at tuxdriver.com> wrote:
> > 
> > On Fri, Sep 01, 2017 at 11:04:00AM +0100, Bruce Richardson wrote:
> >> 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>
> >> Reviewed-by: Harry van Haaren <harry.van.haaren at intel.com>
> > 
> > I feel like I need to underscore my previous concern here.  While I'm not
> > opposed per-se to a new build system, I am very concerned about the burden that
> > switching places on downstream consumers, in particular distributions (since I
> > represent one of them).  Moving to a new build system with new tools means those
> > tools need to be packaged, tested and shipped, which is a significant work
> > effort.  While it might be a net gain long term, its something you need to keep
> > in mind when making these changes.
> > 
> > I know you've said that we will be keepting the existing build system, I just
> > need to be sure everyone understands just how important that is.
> > 
> > Though perhaps the time frame for keeping the current build system as priarmy is
> > less concerning, as feature parity is even more critical.  That is to say, the
> > new build system must be able to produce the same configurations that the
> > current build system does.  Without it I don't think anyone will be able to use
> > it consistently, and that will leave a great number of users in a very poor
> > position.  I think getting a little closer to parity with the current system is
> > warranted.  I'd suggest as a gating factor:
> > 
> > 1) Building on all supported arches
> > 2) Cross building on all supported arches
> > 3) Proper identification of targeted machine (i.e. equivalent of the machine
> > component of the current build system)
> 
> I think your concerns are important and we have to keep the current build system even after the new build system is at parity with the current one. We most likely will have to keep the current build system around for a while like year or more as it will be hard for all distros to convert and add the needed tools to build with DPDK. The problem will be making sure changes in one are reflected in the other build system.
> 
> The new build system has a lot of advantages and Bruce is doing a good job, but we need to open it up into a project for more to contribute, which I assume is the goal here.
> 
No argument, Bruce is doing a fine job here, and while I don't really agree with
the choice of tools, I have to admit its fast and somewhat slick.  But I do feel
strongly about being very careful with how we procede in its introduction.  

Neil