From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BF770A0545; Tue, 21 Jun 2022 16:20:41 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 632C64069C; Tue, 21 Jun 2022 16:20:41 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 5792740151 for ; Tue, 21 Jun 2022 16:20:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655821239; x=1687357239; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=NaNURHGljP5dUzAmqCNVcBsXyxGDw1XSu7vhFQSd+Ho=; b=XeLx2nuHoLc7TH8LAizVPfOpNuJXLrEGKZjWhM+rpixrIFRkmqjeH92e gaxKi9KyZzuy/VJu2FiAX0UQxYRDpDP5VwbXu82HwU5O81Ta01Ds/OS2Y kL4CxQ8a0OEvWUVfC77q9bf1o4PmHSDxZI5E73s5/W5J+khPpc7pbnKzM jlAcvBhJ0ZulGkhVZgn1ZTLFa5ax7uEZnHt5MgtMoihQC4KOe4m+4B9yc S+0GRId0YkusOHEroOigvqe2dlW0u3PyCt+/1YbqhnUv8rrSYWTAldabC D11CNK+cJTVGdbLt7KdPRbaxbqUeM86U3LatDpm1BBByuTgNWEtlKb8Pk g==; X-IronPort-AV: E=McAfee;i="6400,9594,10384"; a="344120965" X-IronPort-AV: E=Sophos;i="5.92,209,1650956400"; d="scan'208";a="344120965" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2022 07:20:38 -0700 X-IronPort-AV: E=Sophos;i="5.92,209,1650956400"; d="scan'208";a="643644087" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.10.248]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 21 Jun 2022 07:20:35 -0700 Date: Tue, 21 Jun 2022 15:20:32 +0100 From: Bruce Richardson To: =?utf-8?Q?Stanis=C5=82aw?= Kardach Cc: Thomas Monjalon , David Christensen , David Marchand , dev , upstream@semihalf.com, Aaron Conole , "Ananyev, Konstantin" , "Ruifeng Wang (Arm Technology China)" , Jerin Jacob Kollanukkaran Subject: Re: [PATCH 0/3] Fix xmm_t to rte_xmm_t scalar conversion Message-ID: References: <20220609121701.716299-1-kda@semihalf.com> <4127934.SvYEEZNnvj@thomas> <3457544.ZfL8zNpBrT@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Jun 21, 2022 at 02:37:51PM +0200, Stanisław Kardach wrote: > On Tue, Jun 21, 2022 at 1:53 PM Thomas Monjalon wrote: > > > > If it is made intentionally hard, it is just a wrong design. > > A toolchain prefix is just a name. > > We can have 2 toolchains compiled with the same name and different behaviours. > > And we can have 2 similar toolchains with a different name. > I don't think meson will allow it anytime soon (see [1]). The > reasoning being that it's easy to screw up the environment and not > notice it where as files are persistent. > > > > > So should the direction be environment or rather separating > > > cross-files into arch-part and toolchain-parts and letting user create > > > his own toolchain part while maintaining a matrix of supported > > > combinations for CI? I'm not advocating either, just want to wrap my > > > head around it. > > > > We should be able to use a toolchain compiled anywhere > > without modifying the cross files, just because a "-gnu-" is missing > > or any other irrelevant detail. > I've checked that if I remove the binaries from a cross-file, then > specifying CC/CXX/AR/STRIP environment variables is picked up by > meson: > AR=riscv64-unknown-linux-gnu-ar \ > STRIP=riscv64-unknown-linux-gnu-strip \ > CC=riscv64-unknown-linux-gnu-gcc \ > CXX=riscv64-unknown-linux-gnu-g++ \ > meson build-rv-test --cross-file=config/riscv/riscv64_linux_gcc > But then there are no default values. > > A suggested frankenstein-like solution in [1] is to use a script that > generates a cross-file with [constants] section and launches meson > with it. > > [1] https://github.com/mesonbuild/meson/issues/9#issuecomment-381410972 This is all incidental to the original fix, which is to replace cpp with g++ in the existing cross files. Any update to how cross files are used by our DPDK scripts, is a different discussion for a different day! [Sorry to have brought it up here, it just seemed somewhat relevant at the time!]