From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id A2FEA3770 for ; Mon, 4 Sep 2017 15:42:36 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 06:42:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,474,1498546800"; d="scan'208";a="145299120" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.24]) by orsmga005.jf.intel.com with SMTP; 04 Sep 2017 06:42:33 -0700 Received: by (sSMTP sendmail emulation); Mon, 04 Sep 2017 14:42:31 +0100 Date: Mon, 4 Sep 2017 14:42:30 +0100 From: Bruce Richardson To: "Van Haaren, Harry" Cc: "dev@dpdk.org" Message-ID: <20170904134230.GA22056@bricha3-MOBL3.ger.corp.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] [PATCH 00/17] build DPDK libs and some drivers with meson/ninja 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: Mon, 04 Sep 2017 13:42:38 -0000 On Mon, Sep 04, 2017 at 02:23:13PM +0100, Van Haaren, Harry wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Friday, September 1, 2017 11:04 AM > > To: dev@dpdk.org > > Cc: Richardson, Bruce > > Subject: [dpdk-dev] [PATCH 00/17] build DPDK libs and some drivers with meson/ninja > > > > Following on from the two previous RFCs [1] [2], here is a cleaned up > > patchset to serve as a start-point for getting all of DPDK building with > > meson and ninja. > > > > What's covered: > > * Basic infrastructure for feature detection and DPDK compilation > > * Building of all DPDK libraries - as either static or shared > > * Compilation of igb_uio driver for Linux > > * Building a number of mempool, crypto and net drivers. > > * Installation of compiled libraries and headers > > * Installation of usertools scripts > > * Compilation of testpmd as dpdk-testpmd and install of same > > * Generation and installation of pkgconfig file for DPDK > > * Contributors guide document addition describing how to add build scripts > > > > What's not implemented: > > * Just about everything else :-), including > > * Support for non-x86 architectures, including cross-compilation > > * Lots of PMDs > > * Support for building and running the unit tests > > > > Some key differences from RFC2: > > * Removed duplication between the different driver meson files by moving > > the build logic up one level to the driver/meson.build file. > > * Added a build option to allow versioning the libraries using the DPDK > > version number, rather than individual .so versions. > > * Made EAL a default dependency for libs, to simplify meson.build files for > > a number of them. > > * Made the build variables used for libraries and drivers more consistent. > > * Moved responsibility for determining if a given driver or library should > > be built to the driver/library's own build file, giving a single place > > where all details about that component are placed, and saving having lots > > of environment detection logic in higher-level build files. > > * Begun adding in developer documentation to make it easier for driver > > authors/maintainers to contribute. > > > > Meson 0.41 and ninja are needed, and ideally meson 0.42 is recommended. > > Ninja is available in most distributions, and meson - if an updated version > > is not available on your distro of choice - can be easily got using > > "pip3 install meson" > > > > To build and install then use: > > > > meson build # use default compiler and shared libs > > cd build > > ninja > > sudo ninja install > > > > Thereafter to use DPDK in other build systems one can use: > > > > pkg-config --cflags DPDK > > pkt-config --libs DPDK > > > > to query the needed DPDK build parameters. > > > > Once reviewed and tested a bit, I hope to apply this set - or a new > > revision of it - to the build-next tree, to serve as a baseline for others > > to use and to add the missing functionality to. > > git / file stats > > A good start - applied cleanly and compiled fine on dpdk-next-build tree. > > Some notes from experience of testing on an Ubuntu 16.04 system: > - libpcap wasn't detected successfully - on researching the transitional package "libpcap-dev" was installed, but that didn't actually install any of the required files. Installing "libpcap0.8-dev" enabled pcap to be detected successfully. No fault of Meson or these patches, just an inconsistency in transitional-packages it seems. The great thing about all this is that it didn't break your build - it just didn't compile the pcap driver for you. :-) > > - Binaries after a compile are in a different location (compared to mk build system). eg: testpmd now resides in app/test-pmd/dpdk-testpmd. No issue, just a note that the path to the binaries changes. With the very-easy "ninja install" and "ninja uninstall", dpdk applications can just be run directly from the installed location (assuming binaries placed on PATH). > > - Ninja install is required with shared-object builds, to enable the dpdk binary (eg: testpmd) to find the .so objects. Doing a local compile (without install) and running ./app/test-pmd/dpdk-testpmd will print "MBUF: error setting mempool handler" and rte_panic(). This is obviously not an issue for static builds - the functionality is linked into the application in that case. Yep, this is an issue, but I'm not sure of a good way round it just now. I made this set very much with the idea in mind that people would use "ninja install" a lot to expose their binaries when running DPDK. If this is not the case and we need a better solution, I'm open to ideas. > > - Some compilers don't correctly expose their capabilities in warning flags causing Meson to believe that it should turn of these warnings. In the current Meson build code, these two warnings are nullified globally: -Wno-format-truncation and -Wno-address-of-packed-member. GCC 5.4.0 and 4.8.5 suffer from both incorrectly exposed. Gcc 7 does not have an issue with -Wno-format-truncation, but the other remains. Clang 3.8.0 does not have any issues. Just something to be aware of - no issues here either. > A little unclear what the problem is here? We record the flags that may be needed to compile up the code, and then apply those to the compilers that support them. It may be that some versions of a compiler don't need the flag when compiling the code, while others do, but this is hopefully rare enough that the simplicity gained from just using the flag when supported well out-weighs the downsides, of unnecessarily disabling a few warnings. The alternative of tracking different warnings for different compiler versions seems rather scary to me :-) > - Build options are set using mesonconf tool, run it to see current configuration, or use it to eg enable static libraries: mesonconf -Ddefault_library=static Actually, to build static libs, you don't need mesonconf at all. You can use --default-library=static as a flag directly to meson. Similarly, you can pass the DPDK=specific flags using -Dx=y syntax to meson. > > Summary so far; > - Only very minor issues found - resolved easily > - Configure and Build speeds still a breath of fresh air to me :) > > On to reviewing the patches themselves, -Harry Great, thanks for the review. /Bruce