nope. Rust version 1.x can be build by 1.x or 1.(x-1) :(
See: https://guix.gnu.org/blog/2018/bootstrapping-rust/ <https://guix.gnu.org/blog/2018/bootstrapping-rust/> -- wbr, Kirill > On 13. Dec 2022, at 22:27, Dave Allured - NOAA Affiliate via macports-dev > <[email protected]> wrote: > > Is it possible to build recent versions directly with rust-1.54? For > example, mrustc -> rust 1.54 -> rust 1.65? > > > On Tue, Dec 13, 2022 at 12:07 PM Kirill A. Korinsky via macports-dev > <[email protected] <mailto:[email protected]>> > wrote: > David, > > the idea is creating a dependency chain: > > Port rust (version 1.66) depends on rust-1.65 to be build; > Port rust-1.65 depends on rust-1.64 to be build; > Port rust-1.64 depends on rust-1.63 to be build; > ... > Port rust-1.56 depends on rust-1.55 to be build; > Port rust-1.55 depends on rust-1.54 to be build; > Port rust-1.54 depends on mrsutc to be build. > > :) > > When someone would like to add rust 1.67, he need to add port rust-1.66 which > should be used as bootstrap compiler. > > I hate this way, but it is the only way to bootstrap it from scratch. > > When mrust had support new rust, we may cut the tree by removing a lot of > unused ports. > -- > wbr, Kirill > >> On 13. Dec 2022, at 17:53, David Gilman <[email protected] >> <mailto:[email protected]>> wrote: >> >> The work on mrustc is novel but I don't think it solves the issues we have >> here. On modern systems MacPorts uses bootstrap compilers provided by Rust >> upstream. MCL's bootstrap compilers are for older systems. >> >> To update rust, my understanding is that you have to do the usual work of >> rebasing patches (my PR), but you also have to provide the binaries for >> older systems which I could not provide. >> >> >> On Tue, Dec 13, 2022, 11:07 AM Kirill A. Korinsky via macports-dev >> <[email protected] <mailto:[email protected]>> >> wrote: >> Folks, >> >> From the third hand we may build our own bootstrap chain of rust from >> scratch. >> >> Or almost. >> >> We have a https://ports.macports.org/port/mrustc/details/ >> <https://ports.macports.org/port/mrustc/details/> which is able to bootstrap >> 1.54 rust on x86_64 and arm64. >> >> Unfortunately support of i386 isn't yet finished at upstream. I plan to fix >> it, but it requires time and availability of hardware to test it :) >> >> I do have a commits which implements rust bootstrap by cahin: mrustc -> rust >> 1.54 -> rust 1.55 -> rust 1.56; I can start to open PRs to move step-by-step >> and in month we'll have the last rust via this chain. >> -- >> wbr, Kirill >> >>> On 13. Dec 2022, at 16:49, Christopher Jones <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, >>> >>> In my opinion, hosting and maintaining these ‘bootstrap’ compilers outside >>> the macports infrastructure was a poor choice, for all the reasons you >>> mention below. I thought this at the time it was done, and even more so now. >>> >>> Personally, I would suggest you think about a change to how the rust >>> compiler is package, to mirror a bit how things are done with gcc and >>> clang. Namely, move to a model where the version is part of the port name, >>> e.g. the current one would be called something like rust-1.61. >>> >>> The main reason for doing this, is adding a new version would that not >>> remove the previous version, and thus you could simple use it as the >>> bootstrap compiler. So with the above, when you add rust-1.62 that would >>> simple configure itself to bootstrap using the macports rust-1.61 port. >>> >>> Yes, this will require some work to set up. You will need to make all the >>> various rust versions installable along side each other, so some tweaking >>> of the install prefix would be needed. >>> >>> One thing I would do differently though to how gcc/clang do things is I >>> would try and have a single rust port file, that implements all the >>> versions as sub-ports. I suspect most of what each needs can then just be >>> shared , such that what needs to be different for each sub-port is actually >>> not that much. >>> >>> Regarding how users of rust then use these ports, there are a couple options >>> >>> 1. Add a shim port ‘rust’ which simply installs sym-links etc. to the >>> ‘current best version’ that mimics the current installation, i.e. in the >>> main prefix. If done well, users should then be blind to the changes above. >>> 2. Users that want an older rust could explicitly depend on and use a >>> specific versioned rust-N >>> >>> For me, this approach makes a lot more sense than the current way these >>> bootstrap compilers are maintained. >>> >>> cheers Chris >>> >>>> On 13 Dec 2022, at 2:57 pm, Herby G <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hello all, >>>> >>>> Right now, Rust in MacPorts is severely out of date. It's about 5 versions >>>> behind the current release, which at the moment is at 1.65.0. In >>>> comparison, MacPorts Rust is currently at 1.61.0. >>>> >>>> As a core language underlying a lot of other ports, many of these ports >>>> cannot be updated to their latest versions because these versions require >>>> current versions of Rust. At the time of this writing, 156 ports are being >>>> built using Rust ( https://ports.macports.org/port/rust/details/ >>>> <https://ports.macports.org/port/rust/details/> ), some quite heavily used >>>> by the community, including projects like `git-delta`, `bat` and `fd`. >>>> >>>> MarcusCalhoun-Lopez's PR here ( >>>> https://github.com/macports/macports-ports/pull/14277 >>>> <https://github.com/macports/macports-ports/pull/14277> ) heavily rewrote >>>> the Rust port to run on older systems, and was very much celebrated and >>>> endorsed. However, as a result of this PR, the Rust port became a lot more >>>> complicated, and also introduced a new critical bootstrap compiler >>>> (referenced in the Rust portgroup here: >>>> https://github.com/macports/macports-ports/blob/2d39b30a32fcf0f5e1cff04f172e9d55ae08ba48/_resources/port1.0/group/rust-1.0.tcl#L140 >>>> >>>> <https://github.com/macports/macports-ports/blob/2d39b30a32fcf0f5e1cff04f172e9d55ae08ba48/_resources/port1.0/group/rust-1.0.tcl#L140>), >>>> which is being hosted in MarcusCalhoun-Lopez's personal Github account ( >>>> https://github.com/MarcusCalhoun-Lopez/rust/releases >>>> <https://github.com/MarcusCalhoun-Lopez/rust/releases> ). Marcus did try >>>> to ask about a more official location to host the bootstrap compiler in a >>>> macports-dev thread: >>>> https://lists.macports.org/pipermail/macports-dev/2022-April/044243.html >>>> <https://lists.macports.org/pipermail/macports-dev/2022-April/044243.html> >>>> , but ultimately per the responses he decided to just host it in his >>>> personal account himself. >>>> >>>> Since this massive change to the Rust port at 1.60.0, it's only seen one >>>> update since then to 1.61.0 ( >>>> https://github.com/macports/macports-ports/commit/8431ccb48eec4824736eca51f643523356091cd6 >>>> >>>> <https://github.com/macports/macports-ports/commit/8431ccb48eec4824736eca51f643523356091cd6> >>>> ) >>>> >>>> David Gilman opened a PR recently attempting to update Rust to 1.64.0 ( >>>> https://github.com/macports/macports-ports/pull/16329 >>>> <https://github.com/macports/macports-ports/pull/16329> ), but Gilman >>>> doesn't have access to update the bootstrap compiler, because as of right >>>> now, only MarcusCalhoun-Lopez knows how to build it, and also it's hosted >>>> in Calhoun's Github account as mentioned prior. >>>> >>>> We need to figure out a more sustainable approach for this bootstrap >>>> compiler, including how it can be built, and hosting it somewhere where a >>>> small set of MacPorts maintainers can build and update it so that we can >>>> get MacPorts Rust back on track. As things are today, only >>>> MarcusCalhoun-Lopez has all the pieces required to update this port, and >>>> there's been no word from him for months now as the Rust port has fallen >>>> further and further behind. Being such a critical core language port, it >>>> may make sense to create a repo within the MacPorts Github organization >>>> where a set of maintainers can host and update the Rust bootstrap compiler.
signature.asc
Description: Message signed with OpenPGP
