On Thu, Sep 07, 2017 at 04:47:00PM +0000, Wiles, Keith wrote: > > > On Sep 7, 2017, at 9:21 AM, Neil Horman <nhor...@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.richard...@intel.com> > >> Reviewed-by: Harry van Haaren <harry.van.haa...@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
