From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 219467CC8 for ; Thu, 7 Sep 2017 18:47:03 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2017 09:47:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,359,1500966000"; d="scan'208";a="126547129" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga004.jf.intel.com with ESMTP; 07 Sep 2017 09:47:02 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 7 Sep 2017 09:47:01 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.18]) by FMSMSX102.amr.corp.intel.com ([169.254.10.194]) with mapi id 14.03.0319.002; Thu, 7 Sep 2017 09:47:01 -0700 From: "Wiles, Keith" To: Neil Horman CC: "Richardson, Bruce" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [dpdk-dev, 01/17] build: add initial infrastructure for meson & ninja builds Thread-Index: AQHTJ/WYoKEEdDek+U6IW+N3ltERqqKqF0YA Date: Thu, 7 Sep 2017 16:47:00 +0000 Message-ID: References: <20170901100416.80264-2-bruce.richardson@intel.com> <20170907162157.GA18344@hmswarspite.think-freely.org> In-Reply-To: <20170907162157.GA18344@hmswarspite.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.224.113] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-dev, 01/17] build: add initial infrastructure for meson & ninja builds 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, 07 Sep 2017 16:47:04 -0000 > On Sep 7, 2017, at 9:21 AM, Neil Horman wrote: >=20 > 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 >>=20 >> 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 sa= me >> globals. >>=20 >>> From the top level build file, the only include file thus far is for th= e >> config folder, which does some other setup of global configuration >> parameters, including pulling in architecture specific parameters from a= n >> 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 thi= s >> 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. >>=20 >> Signed-off-by: Bruce Richardson >> Reviewed-by: Harry van Haaren >=20 > 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 burde= n that > switching places on downstream consumers, in particular distributions (si= nce I > represent one of them). Moving to a new build system with new tools mean= s those > tools need to be packaged, tested and shipped, which is a significant wor= k > effort. While it might be a net gain long term, its something you need t= o keep > in mind when making these changes. >=20 > 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. >=20 > Though perhaps the time frame for keeping the current build system as pri= army 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 po= or > position. I think getting a little closer to parity with the current sys= tem is > warranted. I'd suggest as a gating factor: >=20 > 1) Building on all supported arches > 2) Cross building on all supported arches > 3) Proper identification of targeted machine (i.e. equivalent of the mach= ine > component of the current build system) I think your concerns are important and we have to keep the current build s= ystem 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 i= n 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 a= ssume is the goal here. >=20 > Specific notes inline >=20 >> --- >> config/meson.build | 69 +++++++++++++++++++++++++++++++++++++++++ >> config/rte_config.h | 50 ++++++++++++++++++++++++++++++ >> config/x86/meson.build | 70 ++++++++++++++++++++++++++++++++++++++++++ >> meson.build | 83 ++++++++++++++++++++++++++++++++++++++++++++= ++++++ >> meson_options.txt | 6 ++++ >> 5 files changed, 278 insertions(+) >> create mode 100644 config/meson.build >> create mode 100644 config/rte_config.h >> create mode 100644 config/x86/meson.build >> create mode 100644 meson.build >> create mode 100644 meson_options.txt >>=20 >> diff --git a/config/meson.build b/config/meson.build >> new file mode 100644 >> index 000000000..3a6bcc58d >> --- /dev/null >> +++ b/config/meson.build >> @@ -0,0 +1,69 @@ >> +# BSD LICENSE >> +# >> +# Copyright(c) 2017 Intel Corporation. All rights reserved. >> +# All rights reserved. >> +# >> +# Redistribution and use in source and binary forms, with or without >> +# modification, are permitted provided that the following conditions >> +# are met: >> +# >> +# * Redistributions of source code must retain the above copyright >> +# notice, this list of conditions and the following disclaimer. >> +# * Redistributions in binary form must reproduce the above copyrig= ht >> +# notice, this list of conditions and the following disclaimer in >> +# the documentation and/or other materials provided with the >> +# distribution. >> +# * Neither the name of Intel Corporation nor the names of its >> +# contributors may be used to endorse or promote products derived >> +# from this software without specific prior written permission. >> +# >> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS >> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS F= OR >> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGH= T >> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTA= L, >> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, >> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON A= NY >> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT >> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE U= SE >> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE= . >> + >> +# set the machine type and cflags for it >> +machine =3D get_option('machine') >> +dpdk_conf.set('RTE_MACHINE', machine) >> +add_project_arguments('-march=3D@0@'.format(machine), language: 'c') > So, in the current build system, arch defined the process architecture, w= hile > 'machine' defined the specific processor family (nhm, ivb, etc). This se= ems > like you are merging those two concepts together. While that seems reaso= nable, > is that going to be workable with non-x86 architectures? >=20 > Have you considered using the cross-script option in meson to define a pe= r arch > build file? That I think would eliminate some of this top level parsing o= f arch > options >=20 >> +# some libs depend on maths lib >> +add_project_link_arguments('-lm', language: 'c') >> + >> +# add -include rte_config to cflags >> +add_project_arguments('-include', 'rte_config.h', language: 'c') >> + >> +# disable any unwanted warnings >> +unwanted_warnings =3D [ >> + '-Wno-address-of-packed-member', >> + '-Wno-format-truncation' >> +] >> +foreach arg: unwanted_warnings >> + if cc.has_argument(arg) >> + add_project_arguments(arg, language: 'c') >> + endif >> +endforeach >> + >> +compile_time_cpuflags =3D [] >> +if host_machine.cpu_family().startswith('x86') >> + arch_subdir =3D 'x86' >> + subdir(arch_subdir) >> +endif >> +dpdk_conf.set('RTE_COMPILE_TIME_CPUFLAGS', ','.join(compile_time_cpufla= gs)) >> + > Likewise, I think if you use the --cross-script approach, this logic gets > eliminated in favor of a file pointer from the command line >=20 > >=20 >=20 >> + >> +# set up some global vars for compiler, platform, configuration, etc. >> +cc =3D meson.get_compiler('c') >> +dpdk_conf =3D configuration_data() >> +dpdk_libraries =3D [] >> +dpdk_drivers =3D [] >> +dpdk_extra_ldflags =3D [] >> + >> +# for static libs, treat the drivers as regular libraries, otherwise >> +# for shared libs, put them in a driver folder >> +if get_option('default_library') =3D=3D 'static' >> + driver_install_path =3D get_option('libdir') >> +else >> + driver_install_path =3D '@0@/dpdk/drivers'.format(get_option('prefix')= ) >> +endif >> + > So, I like this, as it appears to default to shared library builds, which= is > great. Unfortunately, it doesn't seem to work for me when using this com= mand: >=20 > meson -Ddefault_library=3Dstatic -Dlibdir=3D./build/lib . build In a previous version of the build system I just edited the meson_option.tx= t file can changed it to static and that worked. The command line should wo= rk, but have not tried that option. >=20 > If I do that and then run ninja in my build directory, I still get DSO's = not > static libraries. I am assuming that I'm doing something subtly wrong in= my > build, but I can't seem to see what it is. >=20 > On the other hand, if static builds don't work yet, thats going to be an = issue. >=20 > >=20 >> +# configure the build, and make sure configs here and in config folder = are >> +# able to be included in any file. We also store a global array of incl= ude dirs >> +# for passing to pmdinfogen scripts >> +global_inc =3D include_directories('.', 'config') >> +subdir('config') >> + >> +# TODO build libs and drivers >> + >> +# TODO build binaries and installable tools >> + > This seems outdated, but I think you remove it in a later patch >=20 > Neil Regards, Keith