From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id BABAC37A0 for ; Mon, 4 Sep 2017 15:23:16 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 06:23:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,474,1498546800"; d="scan'208";a="307762594" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga004.fm.intel.com with ESMTP; 04 Sep 2017 06:23:14 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by IRSMSX154.ger.corp.intel.com ([169.254.12.83]) with mapi id 14.03.0319.002; Mon, 4 Sep 2017 14:23:14 +0100 From: "Van Haaren, Harry" To: "Richardson, Bruce" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 00/17] build DPDK libs and some drivers with meson/ninja Thread-Index: AdMlgGT+YZYkltvOSfWsEQIPzWZbIA== Date: Mon, 4 Sep 2017 13:23:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDJiOGVmYWItYWY2My00MGVkLWJhMTEtYzVjYWU4YjY3M2FjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFnOUpsc00wR1BieFk0aE40K2Vhc3ljd3FZOTd0c2dlQjVHblE3QlJvbU09In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:23:17 -0000 > 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 m= eson/ninja >=20 > 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. >=20 > 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 script= s >=20 > 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 >=20 > 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 f= or > 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 shoul= d > 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 lo= ts > of environment detection logic in higher-level build files. > * Begun adding in developer documentation to make it easier for driver > authors/maintainers to contribute. >=20 > 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 versi= on > is not available on your distro of choice - can be easily got using > "pip3 install meson" >=20 > To build and install then use: >=20 > meson build # use default compiler and shared libs > cd build > ninja > sudo ninja install >=20 > Thereafter to use DPDK in other build systems one can use: >=20 > pkg-config --cflags DPDK > pkt-config --libs DPDK >=20 > to query the needed DPDK build parameters. >=20 > 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 other= s > 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 pa= ckage "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 i= n transitional-packages it seems. - Binaries after a compile are in a different location (compared to mk buil= d 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 "ninj= a install" and "ninja uninstall", dpdk applications can just be run directl= y from the installed location (assuming binaries placed on PATH). - Ninja install is required with shared-object builds, to enable the dpdk b= inary (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 fo= r static builds - the functionality is linked into the application in that = case.=20 =20 - Some compilers don't correctly expose their capabilities in warning flags= causing Meson to believe that it should turn of these warnings. In the cur= rent Meson build code, these two warnings are nullified globally: -Wno-form= at-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-form= at-truncation, but the other remains. Clang 3.8.0 does not have any issues.= Just something to be aware of - no issues here either. - Build options are set using mesonconf tool, run it to see current confi= guration, or use it to eg enable static libraries: mesonconf -Ddefault_li= brary=3Dstatic 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