From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6546088382730076160 X-Received: by 2002:a19:d48f:: with SMTP id l137-v6mr7275lfg.39.1524138144931; Thu, 19 Apr 2018 04:42:24 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:dbd7:: with SMTP id t84-v6ls772351lfi.16.gmail; Thu, 19 Apr 2018 04:42:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoOeFB6IrswROqxsbNfPB0O5zURRld1DQKHU5cr7S7RpME+/e2pI0LQklf4cBGcIvd9/mTr X-Received: by 2002:a19:c354:: with SMTP id t81-v6mr8125lff.1.1524138144306; Thu, 19 Apr 2018 04:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524138144; cv=none; d=google.com; s=arc-20160816; b=ETm38uAZBCmTzQCXXNxpvurHdSqDEfw63YIJCvZOXBy7HQhV4BuaYBsJZs2cLJsZU0 tVV6tXcuC/BL0ZkDL5bWt8qM0eawxGXEHc/xbAxfLeofJacnbob2bjPnCjZki9sGjakh 8zzUIBltiEsRlfk/EFVTtGM7hhclhG37QzqbymbvSSnQ59N4htTZXdi1PD7D9g31WG7q cs6Kawdjrs4jQCvuGOYTFlYveDGLBkPpD+WPS1yHuNNfF1Pwmvy5QJyVAYqEE6nNFTuq DZMkQJ9FM0AQggvWWcr0kP1TETM1qOLHD1nRj6rxi3F1xI4Eg4uyzZUcI+o/oSGF55dr fjgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:openpgp:from:references:cc:to:subject :arc-authentication-results; bh=EJv58vKNNPdPJ4zbvZED7T50gBK4/AnH6BtG6UA5mcs=; b=OnDHPs1D7ZwnqgzBfg2DM+LAW/3iar597JXmfLrLaTQqtDRcRO6QmS07SxD12KKcR4 AxHZiHIrweaNPJ0FmgY6GlKwgbtrOcIYTnglPX/bOGp9pbhmGPhApTRAcjCx0LJzItE2 /ZYZkob8z0M9GlWfIp6rWf81WxCD/xkK5MnqpP+xesWdjHvXP1lKFNtiEr2k1Itsiwv7 5zX0ogNb+63polnUNIBHWrQv8AFE1q8TOEFNr1y2jFprhBcnExNHh64aCZFt2gA3Az3P yTFMMrHmEKncuZBHe86RyASqpBs+DyrVzDd9HhmRWIoEa4TcI+ZWM431oIcei2wmdh4k 6kuA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id a19-v6si154930lfi.1.2018.04.19.04.42.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 04:42:24 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w3JBgNf6008412 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 19 Apr 2018 13:42:23 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w3JBgNdQ025711; Thu, 19 Apr 2018 13:42:23 +0200 Subject: Re: [PATCH] Correctly use the bitbake variable S from now on To: Henning Schild Cc: isar-users@googlegroups.com References: <20180419092602.7791-1-henning.schild@siemens.com> <17ad58e3-a7f1-384e-cd8b-3cbb1caa53b8@siemens.com> <20180419123605.622b6b1c@mmd1pvb1c.ad001.siemens.net> From: Jan Kiszka Openpgp: preference=signencrypt Message-ID: Date: Thu, 19 Apr 2018 13:42:22 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20180419123605.622b6b1c@mmd1pvb1c.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: XsumDNLiag3p 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"). Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux