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 4EC4DC4332F for ; Thu, 15 Dec 2022 21:45:47 +0000 (UTC) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by mx.groups.io with SMTP id smtpd.web11.147400.1671140743658449776 for ; Thu, 15 Dec 2022 13:45:43 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: gmail.com, ip: 209.85.166.181, mailfrom: aehs29@gmail.com) Received: by mail-il1-f181.google.com with SMTP id z9so338626ilu.10 for ; Thu, 15 Dec 2022 13:45:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1UpfZfRQvxXdK3+ndJ+9yMSmxN3W5SzOaRGcmgGsk7Q=; b=XpfpmbPuyeyPLUK+6hEKbjRmBr94K6Re/yozwa0RM3GwHDNbeAGNZvT+gj201gAyxe gEAhomGaaZEUyANynH3A2Ipr5lEjhwLTsd2gT91ANHerN1U+ZhcK71hFgbunUkgiBQPK 3tZEwrafq6OZMOst38GOgvmgnDtkErf5kKVqLh6QmQFi5CmaTtKQpSguXbkvI1jvY+8i z/+Jo/ACT7EP2+rxO3xTuFyZIN3DBT7In0Dfd25HSOsCuI+6QDGy/Bar6lc4nqRz/77Z 1cHcDrYrmLXy+8sedIGJEPWU9slt5KGeUG5Pm2bHMNLcBeb8sI3ih8pA3bcdlAr8xqBx YD5w== X-Gm-Message-State: ANoB5plVDXG9hOx7oK7bR8WqyVkmvO/98mVM6ohdYxe8tpu7tTjqoUu4 aJxxZYSvbuNsIYac9ojIXYtUh/lFYJ/WQA== X-Google-Smtp-Source: AA0mqf6hqGTNxlGAqqeqOGh3x2cRfKePih/qhyWcebsmAMhSYrGxd4MH1i0KgPSahg1Dz6WA6lmKag== X-Received: by 2002:a05:6e02:1b0d:b0:304:a619:c3f2 with SMTP id i13-20020a056e021b0d00b00304a619c3f2mr19743675ilv.9.1671140742754; Thu, 15 Dec 2022 13:45:42 -0800 (PST) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id y16-20020a056638229000b0038aa0e5e9cfsm146010jas.75.2022.12.15.13.45.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Dec 2022 13:45:42 -0800 (PST) Received: by mail-il1-f173.google.com with SMTP id d14so336458ilq.11 for ; Thu, 15 Dec 2022 13:45:42 -0800 (PST) X-Received: by 2002:a92:904:0:b0:303:1869:3a84 with SMTP id y4-20020a920904000000b0030318693a84mr25800806ilg.37.1671140742186; Thu, 15 Dec 2022 13:45:42 -0800 (PST) MIME-Version: 1.0 References: <20221215073224.3061128-1-alejandro@enedino.org> <1731096B411C6A99.9432@lists.openembedded.org> In-Reply-To: From: Alejandro Enedino Hernandez Samaniego Date: Thu, 15 Dec 2022 15:45:32 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels To: Alex Kiernan Cc: Alexander Kanavin , OE-core Content-Type: multipart/alternative; boundary="0000000000004ed2be05efe4c623" 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 ; Thu, 15 Dec 2022 21:45:47 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/174728 --0000000000004ed2be05efe4c623 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan wrote: > On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego > wrote: > > > > > > > > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego < > alejandro@enedino.org> wrote: > >> > >> > >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin > wrote: > >>> > >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via > >>> lists.openembedded.org > >>> wrote: > >>> > Ok, I think what we should do first is to actually drop the version > >>> > from all of the .bb file names, and set it once, inside some .inc, > and > >>> > probably next to SRC_URI and tarball checksum. Then this should allow > >>> > a convenient scheme for including and overriding things. > >>> > > >>> > rust_1.65.0.bb - > rust.bb, and so on. > >>> > >>> Oh, and upstream version checks must be kept functional. It needs to > >>> both correctly report a newer version, and match the recipe version > >>> with upstream if it is already the latest. > >>> > >>> Alex > >> > >> > >> How should I test that upstream checks are still functional? > >> > >> > > Actually how would this make it any simpler?, if we remove PV from the > filenames, the correct place to put the variable is in rust-source.inc > since all others include it (rust-cross-canadian, rust, rust-llvm), if like > I said, rust-source.inc gets included from somewhere else, wouldnt that > override PV for the other recipe as well? beating the whole purpose of the > change, this, or creating a new .inc file just for this seems too > convoluted IMO. > > > > If changing RUST_VERSION is too problematic on every upgrade I think > approach #2 its a lot simpler just specifying RUST_VERSION on other recipes > since it would be very seldom used and it wont conflict with upgrades > > > > Actually changing it is clearly straightforward, the problem is that > upgrading the rust version is already tricky because of the need to > regenerate the cargo checksums, so every extra step is something that > you have to remember to do. > > Which leaves me wondering how introducing nightly/beta actually work > with those patches? > I understand that , the checksums/patches shouldn't cause any problem since as its explained in the commit message beta/nightly builds from the exact same sources, hence patches should apply and checksums wouldn't change. I'll be sending a v2 later today Alejandro > > > -- > Alex Kiernan > --0000000000004ed2be05efe4c623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com> wrote:
On Thu, Dec 15, 2022 at 6:24 PM Aleja= ndro Enedino Hernandez Samaniego
<alejandro@enedino.org> wrote:
>
>
>
> On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego &l= t;alejandro@enedino.org> wrote:
>>
>>
>> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanav= in@gmail.com> wrote:
>>>
>>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via
>>> lists.openembedded.org <alex.kanavin=3D<= a href=3D"mailto:gmail.com@lists.openembedded.org" target=3D"_blank" rel=3D= "noreferrer">gmail.com@lists.openembedded.org>
>>> wrote:
>>> > Ok, I think what we should do first is to actually drop t= he version
>>> > from all of the .bb file names, and set it once, inside s= ome .inc, and
>>> > probably next to SRC_URI and tarball checksum. Then this = should allow
>>> > a convenient scheme for including and overriding things.<= br> >>> >
>>> > rust_1.65.0.bb - > rust.bb, and so on.<= br> >>>
>>> Oh, and upstream version checks must be kept functional. It ne= eds to
>>> both correctly report a newer version, and match the recipe ve= rsion
>>> with upstream if it is already the latest.
>>>
>>> Alex
>>
>>
>> How should I test that upstream checks are still functional?
>>
>>
> Actually how would this make it any simpler?, if we remove PV from the= filenames, the correct place to put the variable is in rust-source.inc sin= ce all others include it (rust-cross-canadian, rust, rust-llvm), if like I = said, rust-source.inc gets included from somewhere else, wouldnt that overr= ide PV for the other recipe as well? beating the whole purpose of the chang= e, this, or creating a new .inc file just for this seems too convoluted IMO= .
>
> If changing RUST_VERSION is too problematic on every upgrade I think a= pproach #2 its a lot simpler just specifying RUST_VERSION on other recipes = since it would be very seldom used and it wont conflict with upgrades
>

Actually changing it is clearly straightforward, the problem is that
upgrading the rust version is already tricky because of the need to
regenerate the cargo checksums, so every extra step is something that
you have to remember to do.

Which leaves me wondering how introducing nightly/beta actually work
with those patches?

I understand that , the checks= ums/patches shouldn't cause any problem since as its explained in the c= ommit message beta/nightly builds from the exact same sources, hence patche= s should apply and checksums wouldn't change.
I'll be sending a v2 later today

Alejandro=C2=A0




--
Alex Kiernan
--0000000000004ed2be05efe4c623--