From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 0DAD737A0 for ; Thu, 22 Jun 2017 22:27:14 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP; 22 Jun 2017 13:27:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,374,1493708400"; d="scan'208";a="118174467" Received: from bricha3-mobl3.ger.corp.intel.com ([10.252.20.151]) by fmsmga006.fm.intel.com with SMTP; 22 Jun 2017 13:27:12 -0700 Received: by (sSMTP sendmail emulation); Thu, 22 Jun 2017 21:27:11 +0100 Date: Thu, 22 Jun 2017 21:27:11 +0100 From: Bruce Richardson To: Neil Horman Cc: Bruce Richardson , dev@dpdk.org Message-ID: <20170622202710.GA93176@bricha3-MOBL3.ger.corp.intel.com> References: <20170607104743.275149-1-bruce.richardson@intel.com> <20170622171454.GA30169@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170622171454.GA30169@hmswarspite.think-freely.org> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.1 (2017-04-11) Subject: Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 20:27:15 -0000 On Thu, Jun 22, 2017 at 01:14:54PM -0400, Neil Horman wrote: > On Wed, Jun 07, 2017 at 11:47:42AM +0100, Bruce Richardson wrote: > > Hi all, > > > > following on from the pressing need to add support in DPDK for detecting > > and managing external dependencies, I undertook to see what options we had. > > However, unrelated to this, over time, I have become increasingly > > frustrated by the complexity of the DPDK configuration and build system. As > > such, I feel that looking at some of the newer build tools that are out > > there might give us the additional functionality we want, along with other > > benefits. As such, I undertook a prototype using "meson"[1] for > > configuration, which uses "ninja" as a backend for doing the actual build. > > > > With these tools we get the following benefits (not a complete list): > > * support for detecting dependencies on the system > > * support for detecting compiler features, including functions, defines > > * improved maintainability through a high-level language, which gives > > decent error messages including line numbers (!!) > > * co-existence with the existing makefile system without making any changes > > to it > > * faster builds using ninja - on my many-core system, the builds seem > > significantly faster than with our existing system. Especially in the > > nothing-has-changed case, builds with my prototype return instantly, > > compared to taking a few seconds to recursively check each directory with > > the current build system > > * the ability to switch to using a standard "ninja" + "ninja install" setup > > * the chance to rework our existing build-config files, and hopefully > > pretty much remove them. > > * pkg-config support. > > * we get to move away from our bespoke build system > > * dependencies in each lib can be moved back to being tracked in the libs > > files themselves, not up a level > > > > > > Of course, it's not a panacea, but having spent hours on the prototype thus > > far, I find working with meson and ninja far more user-friendly than > > working on our makefiles, and again the build speed is a really nice > > improvment too. > > > > The prototype is incomplete, but it does build a reasonable number of our > > libraries, some unit tests, the i40e PMD and the testpmd binary, and I have > > successfully passed traffic using testpmd from the build. Some things are > > not fully correct, e.g. static builds aren't working right now, as I haven't > > correctly done all the dependency tracking, I think, and the cpu flag > > detection has issues. It also has only been tried on x86_64 linux, on a > > couple of systems, so YMMV. However, I feel it's a reasonable enough start > > point to show what we might be able to achieve. > > > > Please take the prototype and test it out. I think it's a better > > alternative to trying to bolt on additional functionality to our existing > > config and build system. > > > > [1] http://mesonbuild.com/ > > A few notes: Hi Neil, thanks for taking a look at this. I agree with all your notes below, and added some comments of my own to each point below. Overall, I fully agree with your conclusion that it's too early to dump make - even the best case plans envisaged for this, would not see make dropped for quite a number of releases [if ever]. > > 1) It is quick for a native build, which is nice > > 2) Its seemingly much more clear to understand than the current Makefile system > (which is horribly opaque). That said, its still not a particularly common > build system. I wonder if there wouldn't be better reception to just cleaning > up the existing Makefiles, with something like autoconf. That likely still > won't be as fast as ninja, but it will be common and well understood, and still > reasonably fast. Sure, that is an option. I decided to look for alternatives mainly because IIRC any mention of autotools in the past has met a very negative reaction on-list. I could be wrong on this but I got the general impression that many thought an autotools cure was better than the disease! :-) Secondly, working with a non-makefile based system allows old and new systems to co-exist for as long as we want them too, without having to do a wholesale replacement, or go to great lengths to manage the two within the one set of (make)files. > > 3) The tools that are needed here, aren't universally available. I can speak to > RHEL specifically which doesn't have ninja currently, nor meson (they are > available in EPEL, but that can't be used for official builds). Its not an > insurmountable problem, but its something to consider when considering product > reach, and the impact this will have on distributions. I'll admit that meson is fairly new, but from what I read it is also gaining quite a bit of acceptance in the gnome world at least, so it's not really that obscure a system. Ninja, on the other hand, has been around since 2011, and is widely used by many other tools, e.g. cmake, gyp and meson, and projects like chromium, or llvm, so I'm a bit surprised that is is not in RHEL. Are other packages compiled using ninja in RHEL? > > 4) I'm a bit lost as to how inheritance works in meson (or if it exists at all). > All the examples you provide here seem to duplicate work. For instance, several > libraries independently check if dpdk_conf.has('RTE_MACHINE_CPUFLAG_SSE4_1') > and set proper cflags accordingly, rather than inheriting the flag from a higher > level. While that in and of itself isn't a singular problem, it could well be a > problem at scale for more complex operations (see below) Yep, good point. Things like that I would always initially blame on my novice implementation as I was learning meson as I went along. If it is really a problem, doing a full implementation should quickly show that up, and we can go back to the drawing board. > > 5) I know you said this was just an incomplete prototype, which is fine, but I > noticed that the build it produces doesn't yield any pmd exported info (of the > type you would get using dpdk-pmdinfo.py). Thats because the building of that > info requires a multi-stage build process, wherein .o files are post-processed > to generate new .c files, which are then compiled and linked into the final .so > or .a file. While I think I see how you might use the gen_src and custom_target > rules to make that happen, the (supposed) lack of inheritance noted above, could > lead to the duplication of alot of fairly complex rules that would have to be > distributed to every pmd in the system. Thats something to consider. Yep. I explicitly decided not to tackle the pmdinfo stuff for the prototype, but I hadn't considered the implications for duplication in the build files. I'll try and dig into this soon before we invest serious work into this. > > 6) Integration with other build systems. We build some kernel modules in dpdk > that likely need to remain as part of the make build system (they don't have to, > I suppose, but it would seem like alot of effort to change that). Is using > something non-make going to fit there? I was assuming we'd still use make for the kernel modules, but haven't tried to see how that would work yet. > > Just a few thoughts. All in all the speed is nice, but I think theres alot to > consider before dumping Make. Not so much because Make is great, but because > its common, and well understood, and integrated with other projects. > Yep, at this point I'd rate it as "definitely worth looking at further", rather than a definite commitment to replace what we have. I'm aiming to start doing a post-prototype implementation in a staging tree in the near future and we can see how that shapes up. /Bruce