From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6546088382730076160 X-Received: by 10.28.158.143 with SMTP id h137mr623116wme.25.1524156983324; Thu, 19 Apr 2018 09:56:23 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.206.14 with SMTP id e14ls144537wmg.11.canary-gmail; Thu, 19 Apr 2018 09:56:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx499gvIVHgcZOBsqp3RGZMs2cN1FtRkYwXh/4jb7eDYL9QiRDxE73hZvf8d2b6VcacNF1jSu X-Received: by 10.28.3.131 with SMTP id 125mr598331wmd.18.1524156982871; Thu, 19 Apr 2018 09:56:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524156982; cv=none; d=google.com; s=arc-20160816; b=L1u3C2nCDUJP5rUEczZbMJMpMSd9YftgiXISluRO1xAX9fde0Zn/WLP/JboYWdNCfs iM1Y0mQ8+iyQ16hE86CIT5s8loHr1PzBegVCxEe8WpG7PhZXv3Hd/UcZc6UXeN1CICAT VGD/+Mmz6rgU+SWNn0p9K5oehJm/7d8Mgzrxjk27lKYlZ8ff0jVeUzeuyzEBbo6T8zpx 9/xMtMxXfC4gEvTdswFdLycXi5GIS+Ar63iGDEKXQkXPckWO4PHGrAETIScya6EO47iU KG/JPg5+86tpJzupDubLPC3QHCpC3TDdCB2dlg9WI502Gjdoz8pL1a5ZoxHjHi40lP+J J03Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=+CyHCA+ssndn44QWpAzMe5qHeaj/1UCPqaB6yixxurw=; b=oy/qHnqS2WCrTrqREHPjt0q/BcYVAbuP00/+XsvuA7TVcUHSPjPZENz5pTcQoWGbyA D/n9C/hBZ0AgqyctlwFSypeUHiHxdOlHKDYbM0FBksjYrf0EJk9vb4wCLDaA9zqOpkPZ 03Vx/7YkNyOFRIdDBEiJg209G7Y/LLa3Uw6/PdogAqBPu362X/Vm5CoUUPT4EAA59hMW 9Fj8Hz1wpUrAbQsWpA2QGPrX7gC8IR7DPRkVeTDlc3uck5002V0bIj43IHSfhB/kKMSB FtweXQvteEytcxNsDNAvrGmBzzAzssSjtqohwL8QrpyQUQ6EbKEXrdOVNGi+7ZcGz9g6 tyeg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id g12-v6si87808wrm.4.2018.04.19.09.56.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 09:56:22 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w3JGuMWA029647 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 19 Apr 2018 18:56:22 +0200 Received: from mmd1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w3JGuMfr032300; Thu, 19 Apr 2018 18:56:22 +0200 Date: Thu, 19 Apr 2018 18:56:21 +0200 From: Henning Schild To: Jan Kiszka Cc: Subject: Re: [PATCH] Correctly use the bitbake variable S from now on Message-ID: <20180419185621.27fc67ec@mmd1pvb1c.ad001.siemens.net> In-Reply-To: References: <20180419092602.7791-1-henning.schild@siemens.com> <17ad58e3-a7f1-384e-cd8b-3cbb1caa53b8@siemens.com> <20180419123605.622b6b1c@mmd1pvb1c.ad001.siemens.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: awqTEpmDyVQ2 Am Thu, 19 Apr 2018 13:42:22 +0200 schrieb Jan Kiszka : > On 2018-04-19 12:36, Henning Schild wrote: > >>> diff --git a/meta/classes/patch.bbclass > >>> b/meta/classes/patch.bbclass index 26a0c81..1559359 100644 > >>> --- a/meta/classes/patch.bbclass > >>> +++ b/meta/classes/patch.bbclass > >>> @@ -5,7 +5,7 @@ python do_patch() { > >>> import subprocess > >>> > >>> workdir = d.getVar("WORKDIR", True) + "/" > >>> - src_dir = workdir + (d.getVar("S", True) or "") > >>> + src_dir = (d.getVar("S", True) or "") > >> > >> That's not equivalent, but I'm undecided if it matters. S should > >> never be unset (bitbake.conf holds the default). So we could just > >> pull S and let the build fail if that assumption should ever be > >> wrong. > > > > I was wondering why the or "" was there in the first place, S was > > always set even before recipes decided to overwrite it. Some python > > sniplets seem to return Null on some intermediate steps when using > > layers. Might that be why you introduced the 'or ""'? > > Problem is that I don't remember doing this intentionally. But if that > were the case (intermediate Null state), it should not longer harm us > now (no more "x + Null"). It was + ed later, but never seem to be Null. V2 on the way. Henning > Jan >