From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Boccassi Subject: Re: [PATCH] build: use generic march on arm64 when using 'default' machine Date: Mon, 07 Jan 2019 13:45:56 +0000 Message-ID: <1546868756.6022.21.camel@debian.org> References: <20181224125627.25690-1-bluca@debian.org> <20190107122401.GA14912@bricha3-MOBL.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, christian.ehrhardt@canonical.com, stable@dpdk.org To: Bruce Richardson Return-path: In-Reply-To: <20190107122401.GA14912@bricha3-MOBL.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 2019-01-07 at 12:24 +0000, Bruce Richardson wrote: > On Mon, Dec 24, 2018 at 01:56:27PM +0100, Luca Boccassi wrote: > > When building for generic distribution we need a stable baseline > > architecture, or depending on the build worker the result will > > vary. > >=20 > > Force the default flags if the user explicitly sets > > marchine=3Ddefault >=20 > typo: marchine >=20 > > at configuration time. > >=20 > > Fixes: b1d48c41189a ("build: support ARM with meson") > > Cc: stable@dpdk.org > >=20 > > Signed-off-by: Luca Boccassi > > --- > > =C2=A0config/arm/meson.build | 7 ++++++- > > =C2=A01 file changed, 6 insertions(+), 1 deletion(-) > >=20 > > diff --git a/config/arm/meson.build b/config/arm/meson.build > > index dae55d6b2..fa21a2fd2 100644 > > --- a/config/arm/meson.build > > +++ b/config/arm/meson.build > > @@ -6,6 +6,7 @@ > > =C2=A0march_opt =3D '-march=3D@0@'.format(machine) > > =C2=A0 > > =C2=A0arm_force_native_march =3D false > > +arm_force_default_march =3D machine =3D=3D 'default' >=20 > Do we need a new variable here? Given it only seems to be used once > below, > I think just having the boolean expression directly in the if > statement is > clearer. If you do keep the variable, suggest putting braces around > the > comparison, otherwise at first glance it looks like a chained > assignment > like you get in C e.g. x =3D y =3D 0; Eheh it looks like I was a bit too hasty - I now remember that the main reason I added a new variable is that the "machine" variable gets overridden just before the if branch, so the original value is lost. I could refactor and rename, but that would be more intrusive so I had opted to just do what was already done for the other "force" case. --=20 Kind regards, Luca Boccassi