From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F3F5C4332F for ; Tue, 31 Oct 2023 12:28:41 +0000 (UTC) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by mx.groups.io with SMTP id smtpd.web10.184610.1698755315474057098 for ; Tue, 31 Oct 2023 05:28:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linuxfoundation.org header.s=google header.b=M+OV/kWW; spf=pass (domain: linuxfoundation.org, ip: 209.85.167.42, mailfrom: richard.purdie@linuxfoundation.org) Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-507bd644a96so8095734e87.3 for ; Tue, 31 Oct 2023 05:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1698755314; x=1699360114; darn=lists.openembedded.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=SlQL2OHyy/Z1dMLWqG6Ih0KreCk//b+l4kfUpE6MN5s=; b=M+OV/kWW4GgjPhhlVH3anSBKIsoxB/TjYGZ6U+ydE3MRtMZTmc2AE15dZs9/F5XQk4 qsvCzWPMGT6bDoIIChzdHtWeqOS5Tcr48rp2jjttl8WxBs9oBM3eZBfVkNosYAQzsKIf aefCS7Dxggvl2zGSNI+j+nHctIlRwadRqfLAY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698755314; x=1699360114; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SlQL2OHyy/Z1dMLWqG6Ih0KreCk//b+l4kfUpE6MN5s=; b=YzX/OPi06ZTlwVe6jXmNxryvTJCarhYJx0zGBZ1KGkHZHAStQchofbOqMqmp2AR8e0 7wqo5cPSvDbwA+faLnIAJPlv3B4BjU+FO27IqBmF4CImHZS0ynNBFGxfmdGS0unFOwpx xtAyQNdoktzSK/Lhpz14VDYFXGnYSu2IFkq/xXgOPHIKEF71w3uuLfAtARdyBW22ADki 9cH4dlzQZ+0osY1ig1so5P+7fsgml2qFMH1x0xoMcyZcRN3GCMdnpR7lyZuo4rbV1Q44 rM+qWNksH7du6t28QtDsLHS0br0iXD0h3JQciIhlnTHlnA8kYWKvDfilCvTxLrKZMJML a9dg== X-Gm-Message-State: AOJu0YxFA587/6tFRWyyO1vrfTA5ZjTHsCqAukcJnAwm98mwyDyfq16i Qc/06u6M/ljkI8HkvLmxid257Q== X-Google-Smtp-Source: AGHT+IHmGL94wA7s7ObpYBkMVRa/Ejh/+ykqM/F4wys8hshWFjM31UKZnw0HSbRb7wesPuTkz2cZGQ== X-Received: by 2002:a05:6512:1586:b0:509:1ecb:5a04 with SMTP id bp6-20020a056512158600b005091ecb5a04mr6286922lfb.19.1698755313588; Tue, 31 Oct 2023 05:28:33 -0700 (PDT) Received: from ?IPv6:2001:8b0:aba:5f3c:9850:4974:d357:58d5? ([2001:8b0:aba:5f3c:9850:4974:d357:58d5]) by smtp.gmail.com with ESMTPSA id w21-20020a05600c475500b00403b63e87f2sm1656660wmo.32.2023.10.31.05.28.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 05:28:33 -0700 (PDT) Message-ID: <7488045369ecd729ac3df2e526a74ee644fbcf26.camel@linuxfoundation.org> Subject: Re: [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused? From: Richard Purdie To: Alexander Kanavin Cc: openembedded-architecture , Yocto-mailing-list , ",openembedded-core@lists.openembedded.org" , Julien STEPHAN Date: Tue, 31 Oct 2023 12:28:32 +0000 In-Reply-To: References: <81f4c191fe6dead1feec6bfc0d36aa328af1f7d4.camel@linuxfoundation.org> <1792EACC19CD8046.7262@lists.openembedded.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.1-0ubuntu1 MIME-Version: 1.0 List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 31 Oct 2023 12:28:41 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/189839 On Tue, 2023-10-31 at 13:08 +0100, Alexander Kanavin wrote: > On Mon, 30 Oct 2023 at 16:02, Alexander Kanavin via > lists.openembedded.org > wrote: > > So here's what could be done: > >=20 > > - esdk tools become symlinks in poky/scripts/esdk-tools/. esdk > > environment script puts that in PATH, rather than some custom > > esdk-specific location (the code to generate that can then be > > dropped). >=20 > This is now implemented (needs to be tested on AB). >=20 > > - esdk tweaks to local.conf move into a dedicated include file, which > > can be static and under version control, except for perhaps > > METADATA_REVISION:poky =3D "4a1e0b9625729e422fcf24e632ee2a3c79f986d5" - > > I need to check why is it there and how that is used. >=20 > It's actually more complicated. The code to generate esdk-specific > local.conf with all the tweaks has too much dynamic stuff in it which > is subject to what various variables are set to. So I'm thinking of > extracting that to a dedicated function, then attaching a bitbake task > to that function. >=20 > Then we can pull all of it together into 'devtool esdk ' > command (or similar), which would enter the esdk environment directly > via: > - running 'bitbake meta-ide-support' > - running the above mentioned bitbake local.conf task to generate the > esdk-specific local.conf > - sourcing the environment script produced by meta-ide-support > - rewriting PATH to provide only the curated esdk tools and not > everything plus bitbake. > - writing a custom devtool.conf similar to that of standalone esdk so > that devtool can find bitbake and bitbake can use the esdk-specific > local.conf >=20 > And it would be tested in the same way standalone esdks are. >=20 > Thoughts? Anything missing from the above list? That sounds like a good way to handle this to me! Cheers, Richard