From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id B302BF72 for ; Mon, 28 May 2018 11:33:49 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 May 2018 02:33:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,451,1520924400"; d="scan'208";a="59139592" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.55]) by fmsmga001.fm.intel.com with SMTP; 28 May 2018 02:33:47 -0700 Received: by (sSMTP sendmail emulation); Mon, 28 May 2018 10:33:45 +0100 Date: Mon, 28 May 2018 10:33:45 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org Message-ID: <20180528093317.GB15204@bricha3-MOBL.ger.corp.intel.com> References: <20180424123255.204330-1-bruce.richardson@intel.com> <20180525145158.5113-1-thomas@monjalon.net> <20180525151858.GA18500@bricha3-MOBL.ger.corp.intel.com> <11072939.itZiRipOQY@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11072939.itZiRipOQY@xps> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v2] devtools: add test script for meson 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: Mon, 28 May 2018 09:33:50 -0000 On Sat, May 26, 2018 at 11:32:53AM +0200, Thomas Monjalon wrote: > 25/05/2018 17:18, Bruce Richardson: > > On Fri, May 25, 2018 at 04:51:58PM +0200, Thomas Monjalon wrote: > > > +default_path=$PATH > > > + > > > +# Load config options > > > +. $(dirname $(readlink -e $0))/load-devel-config > > > + > > > > Why is this needed here, it seems to be called before each individual > > config anyway. > > Right, it can be removed from here. > > > > +reset_env () > > > +{ > > > + export PATH=$default_path > > > + unset CROSS > > > + unset ARMV8_CRYPTO_LIB_PATH > > > + unset FLEXRAN_SDK > > > + unset LIBMUSDK_PATH > > > + unset LIBSSO_SNOW3G_PATH > > > + unset LIBSSO_KASUMI_PATH > > > + unset LIBSSO_ZUC_PATH > > > + unset PQOS_INSTALL_PATH > > > > These variables bar PATH are unused by meson build, so should be removed > > here to avoid giving the impression they are use. > > Actually they should be used when compiling. > PATH can be used to allow a toolchain which is not in the standard path. > And dependencies _PATH variables can be specified only for some builds. > Example: I have libsso only for x86 64-bit, so I do not set it > for 32-bit or ARM builds. The config file reads DPDK_TARGET to know. > Note: DPDK_TARGET is not yet set correctly for every builds in this version. > We don't need DPDK_TARGET variable any more, however, environmental vars can be used by this script for setting up PATH and CFLAGS/LDFLAGS etc. as needed. However, environmental vars bar those standard ones are ignored by a meson build, so they would be only for script use. Therefore I'm suggesting removing only the unused ones. > > $CROSS is used by the > > script so perhaps it can be kept. However, the whole point of the > > cross-files is that you include all the needed details of your compiler > > there. I think we should move away from using the CROSS value completely, > > and use the cross-files properly. > > Yes we can remove CROSS if it is redundant with config files in config/arm/. > But I do not understand why these files cannot be agnostic regarding the > name (CROSS) of the toolchain. > To me it is very strange to have the binary names hard-linked in the configs. > Anyway, this discussion is out of the scope of this script. > So I am for removing the CROSS variable and use aarch64-linux-gnu-gcc > as it is hard written in every ARM configs for now. You can use CROSS in this script to set PATH for each build. Again, though it would only be for script, not meson use. > > > > +cd $(dirname $(readlink -m $0))/.. > > > + > > I don't think we should force the builds to be always put into the base > > directory. Instead of using cd, I think we should instead capture the base > > directory path and pass that to meson. > > OK to not force the directory. > You want to build in the current directory? > If yes, we can just remove this "cd" and no need to pass a base directory > to meson. We would need to pass the base to meson, because otherwise meson assumes the top-level meson.build file is in the current directory, i.e. calling "meson build-dir" is the same as "meson . build-dir". If we want to allow using this script from other places on filesystem, we need to either "cd" to the base dir as you do now, or else explicitly pass in the basedir. The latter I think is a better option as it would allow building from any location on the filesystem. > > > > +load_config () > > > +{ > > > + reset_env > > > + . $(dirname $(readlink -e $0))/load-devel-config > > > + MESON=${MESON:-meson} > > > +} > > Why does this need to be done each time? > > Because the config could be different for each build (see above). > How would it be different, it's the same command called with the same environment each time? /Bruce