Re: The State of Rust in MacPorts Today

[Kevin Reid]

On Tue, Dec 13, 2022 at 7:50 AM Christopher Jones 
wrote:

> … 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. ...
>
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
>

A suggestion: if this is done, the shim port would ideally work in the same
fashion as the "rustup" [1] Rust installation manager tool does. That is,
the command shims are not just symlinks, but a binary that invokes the
chosen version, which can be overridden on a per-project or per-user basis
 [2], or at the command
line with a special command argument like cargo +1.61.0 build. The
advantage this gives users is that MacPorts-installed Rust will
automatically work with existing Rust projects which, for whatever reason,
wish to use a specific toolchain version, as well as typical advice in
tutorials.

Almost certainly, the simplest way to do this would be for the shim port to
actually itself be rustup, configured to know about the MacPorts-installed
versions
 [3].
I believe this should work seamlessly, other than perhaps configuring that
toolchain link and setting the default toolchain (which is essentially like
the port select mechanism in MacPorts) — which could be, at worst, a note
printed at installation telling the user to run the link and default
commands.

This would also allow users who wish to use Rust versions not packaged by
MacPorts to obtain rustup itself from MacPorts.

(rustup has a self-update mechanism, but I believe that can be disabled for
packaged versions.)

[1]: https://rustup.rs
[2]: https://rust-lang.github.io/rustup/overrides.html
[3]: https://rust-lang.github.io/rustup/installation/package-managers.html

Re: The State of Rust in MacPorts Today

[Kirill A. Korinsky via macports-dev]

nope.

Rust version 1.x can be build by 1.x or 1.(x-1) :(

See: https://guix.gnu.org/blog/2018/bootstrapping-rust/ 



--
wbr, Kirill

> On 13. Dec 2022, at 22:27, Dave Allured - NOAA Affiliate via macports-dev 
>  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 
> mailto:macports-dev@lists.macports.org>> 
> 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 > > 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 
>> mailto:macports-dev@lists.macports.org>> 
>> 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/ 
>>  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 >> > 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 >>> > 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 

Re: The State of Rust in MacPorts Today

[Dave Allured - NOAA Affiliate via macports-dev]

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 <
macports-dev@lists.macports.org> 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  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 <
> macports-dev@lists.macports.org> 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/ 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 
>> 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  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/ ), 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 ) heavily rewrote
>> the Rust port to run on older systems, and was very much celebrated and
>> endorsed. However, 

Re: The State of Rust in MacPorts Today

[Sergey Fedorov]

FFMpeg can certainly be compiled without Rust, including the latest
(upstream) version.
Perhaps a component that is pulling in Rust should rather be made an
optional variant for all systems – it is hardly justified to have it as the
default, IMHO.

On Wed, Dec 14, 2022 at 12:32 AM grey  wrote:

> This is a tangential, so please forgive me if this seems as if it is
> the wrong time to bring this up, but I seem to have some Rustaceans
> who may know more about this than I.
>
> I was recently seeing if there might be a way to improve upon the
> FFmpeg ports (there are currently three: ffmpeg, fffmpeg-devel and
> ffmpeg-upstream, though two of them are at the same version presently)
> to reduce the number of dependencies. While I was able to make a go of
> it successfully and included an attempt at a Portfile here:
> https://trac.macports.org/ticket/66424# in the comments Ken suggested
> that since the current MacPorts for FFmpeg have rust as a dependency,
> that brings in a flood of other dependencies.
>
> To be honest, I am unsure why FFmpeg would require rust (it doesn't in
> my builds from upstream's repository if cloning from source nor in my
> Portfile using a versioned release), and it seems as if such things
> may be better separated into a variant, but even in the occasion where
> rust is considered required, does rust really have that many
> dependencies? I guess it is the Kolmogorov complexity reduction spirit
> in me, but am I crazy for thinking that a dependency audit and
> minimizing such things might be worthwhile (probably for more than
> merely FFmpeg, perhaps even the rust MacPort itself)?
>
> Thank you for any insights into a rather unrelated matter.
>
> On Tue, Dec 13, 2022 at 5:21 PM Kirill A. Korinsky via macports-dev
>  wrote:
> >
> > Chris,
> >
> > Clearly some thought has to be given to how to ensure the dependency
> tree does not get too long. We don’t want, when a new OS comes out for it
> to have to build tens of rust versions, just to ultimately bootstrap the
> last one. That might just be keeping the first bootstrap port, mrustc new
> enough at all times such that the list is kept manageable.
> >
> >
> > Unfortunately mrust supports to build rust up to 1.54.
> >
> > As soon as upstream of mrust is updated compiler to something never,
> I'll update the port and short the tree.
> >
> > --
> > wbr, Kirill
> >
> > On 13. Dec 2022, at 18:16, Christopher Jones 
> wrote:
> >
> > Hi,
> >
> > On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev <
> macports-dev@lists.macports.org> 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.
> >
> >
> > Clearly some thought has to be given to how to ensure the dependency
> tree does not get too long. We don’t want, when a new OS comes out for it
> to have to build tens of rust versions, just to ultimately bootstrap the
> last one. That might just be keeping the first bootstrap port, mrustc new
> enough at all times such that the list is kept manageable.
> >
> > Chris
> >
> >
> >
> > 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  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 <
> macports-dev@lists.macports.org> 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/ 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, 

Re: The State of Rust in MacPorts Today

[grey]

This is a tangential, so please forgive me if this seems as if it is
the wrong time to bring this up, but I seem to have some Rustaceans
who may know more about this than I.

I was recently seeing if there might be a way to improve upon the
FFmpeg ports (there are currently three: ffmpeg, fffmpeg-devel and
ffmpeg-upstream, though two of them are at the same version presently)
to reduce the number of dependencies. While I was able to make a go of
it successfully and included an attempt at a Portfile here:
https://trac.macports.org/ticket/66424# in the comments Ken suggested
that since the current MacPorts for FFmpeg have rust as a dependency,
that brings in a flood of other dependencies.

To be honest, I am unsure why FFmpeg would require rust (it doesn't in
my builds from upstream's repository if cloning from source nor in my
Portfile using a versioned release), and it seems as if such things
may be better separated into a variant, but even in the occasion where
rust is considered required, does rust really have that many
dependencies? I guess it is the Kolmogorov complexity reduction spirit
in me, but am I crazy for thinking that a dependency audit and
minimizing such things might be worthwhile (probably for more than
merely FFmpeg, perhaps even the rust MacPort itself)?

Thank you for any insights into a rather unrelated matter.

On Tue, Dec 13, 2022 at 5:21 PM Kirill A. Korinsky via macports-dev
 wrote:
>
> Chris,
>
> Clearly some thought has to be given to how to ensure the dependency tree 
> does not get too long. We don’t want, when a new OS comes out for it to have 
> to build tens of rust versions, just to ultimately bootstrap the last one. 
> That might just be keeping the first bootstrap port, mrustc new enough at all 
> times such that the list is kept manageable.
>
>
> Unfortunately mrust supports to build rust up to 1.54.
>
> As soon as upstream of mrust is updated compiler to something never, I'll 
> update the port and short the tree.
>
> --
> wbr, Kirill
>
> On 13. Dec 2022, at 18:16, Christopher Jones  wrote:
>
> Hi,
>
> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev 
>  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.
>
>
> Clearly some thought has to be given to how to ensure the dependency tree 
> does not get too long. We don’t want, when a new OS comes out for it to have 
> to build tens of rust versions, just to ultimately bootstrap the last one. 
> That might just be keeping the first bootstrap port, mrustc new enough at all 
> times such that the list is kept manageable.
>
> Chris
>
>
>
> 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  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 
>  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/ 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  
>> 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 

Re: The State of Rust in MacPorts Today

[Kirill A. Korinsky via macports-dev]

Chris,

> Clearly some thought has to be given to how to ensure the dependency tree 
> does not get too long. We don’t want, when a new OS comes out for it to have 
> to build tens of rust versions, just to ultimately bootstrap the last one. 
> That might just be keeping the first bootstrap port, mrustc new enough at all 
> times such that the list is kept manageable.

Unfortunately mrust supports to build rust up to 1.54.

As soon as upstream of mrust is updated compiler to something never, I'll 
update the port and short the tree.

--
wbr, Kirill

> On 13. Dec 2022, at 18:16, Christopher Jones  wrote:
> 
> Hi,
> 
>> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev 
>> mailto:macports-dev@lists.macports.org>> 
>> 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.
> 
> Clearly some thought has to be given to how to ensure the dependency tree 
> does not get too long. We don’t want, when a new OS comes out for it to have 
> to build tens of rust versions, just to ultimately bootstrap the last one. 
> That might just be keeping the first bootstrap port, mrustc new enough at all 
> times such that the list is kept manageable.
> 
> Chris
> 
> 
>> 
>> 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 >> > 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 
>>> mailto:macports-dev@lists.macports.org>> 
>>> 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/ 
>>>  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 >>> > 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 

Re: The State of Rust in MacPorts Today

[Christopher Jones]

Hi,

> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev 
>  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.

Clearly some thought has to be given to how to ensure the dependency tree does 
not get too long. We don’t want, when a new OS comes out for it to have to 
build tens of rust versions, just to ultimately bootstrap the last one. That 
might just be keeping the first bootstrap port, mrustc new enough at all times 
such that the list is kept manageable.

Chris


> 
> 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 > > 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 
>> mailto:macports-dev@lists.macports.org>> 
>> 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/ 
>>  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 >> > 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 >>> > 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 

Re: The State of Rust in MacPorts Today

[Kirill A. Korinsky via macports-dev]

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  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 
> mailto:macports-dev@lists.macports.org>> 
> 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/ 
>  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 > > 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 >> > 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/ 
>>>  ), 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 
>>>  ) heavily rewrote 
>>> the Rust port to run on older systems, and was very much 

Re: The State of Rust in MacPorts Today

[David Gilman]

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 <
macports-dev@lists.macports.org> 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/ 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 
> 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  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/ ), 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 ) 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),
> which is being hosted in MarcusCalhoun-Lopez's personal Github account (
> 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
> , 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
> )
>
> David Gilman opened a PR recently attempting to update Rust to 1.64.0 (
> https://github.com/macports/macports-ports/pull/16329 ), but 

Re: The State of Rust in MacPorts Today

[Sergio Had]

Kirill, when you gonna deal with i386, consider also PPC. Sure enough, it is 
not a priority, but it may be fixable, given that mrustc itself builds on ppc32.
To be clear, I do not expect any dedicated fixes, just making sure x86 is not 
hard-coded and 32-bit platforms are supported.
Then all PPC testing can be done on my hardware (second half of Jan, once I am 
home).
On Dec 13, 2022 23:07 +0700, Kirill A. Korinsky via macports-dev 
, 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/ 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  
> > 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  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/ ), 
> > > 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 ) 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),
> > >  which is being hosted in MarcusCalhoun-Lopez's personal Github account ( 
> > > 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 
> > > , 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 ( 
> > > 

Re: Dev guide updated for github/easy instructions?

[Langer, Stephen A. (Fed) via macports-dev]

When I used that page, step 1e was confusing to a git newbie.

-- Steve

From: macports-dev  on behalf of Nils 
Breunese 
Date: Monday, December 12, 2022 at 4:56 PM
To: MacPorts Development 
Subject: Re: Dev guide updated for github/easy instructions?
Does https://guide.macports.org/chunked/project.github.html help?

Nils.

P.S. I believe macports-...@lists.macosforge.org is the old address of this 
mailing list, macports-dev@lists.macports.org is the new one.

> Op 12 dec. 2022, om 16:35 heeft Watson Ladd  het 
> volgende geschreven:
>
> This morning I realized that Pari is lagging behind, so went ahead to
> start contributing a version bump. Unfortunately i completely forgot
> the song and dance to make Macports process the portfile I produced,
> and then the documentation was very pre-github migration (assumes
> individual port files vs checking out the repo).
>
> Perhaps we should have a development guide update, and in the meantime
> do i just update the sources to include my local checkout? I could
> have sworn I've done this before, but just forgot how.
>
> Sincerely,
> Watson
>
> --
> Astra mortemque praestare gradatim

Re: The State of Rust in MacPorts Today

[Kirill A. Korinsky via macports-dev]

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/ 
 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  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 > > 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/ 
>>  ), 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 
>>  ) 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
>>  
>> ),
>>  which is being hosted in MarcusCalhoun-Lopez's personal Github account ( 
>> 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 
>>  , 
>> 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
>>  
>> 
>>  )
>> 
>> David Gilman 

Re: The State of Rust in MacPorts Today

[Christopher Jones]

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  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/ 
>  ), 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 
>  ) 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
>  
> ),
>  which is being hosted in MarcusCalhoun-Lopez's personal Github account ( 
> 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 
>  , 
> 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
>  
> 
>  )
> 
> David Gilman opened a PR recently attempting to update Rust to 1.64.0 ( 
> 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 

Re: The State of Rust in MacPorts Today

[David Gilman]

The thing blocking me, and probably anyone else in the project, from
bumping the version, and also from testing/updating other ports, is
that I don't have access to build machines with older MacOS X
releases. It is probably better to frame this discussion in that way:
how can we get a build environment available to anyone who wants to
build against old MacOS X?

I don't know what MCL had on-hand to build all those binaries, I
thought about reaching out to him off-list to ask but never did. Even
if he's too busy to do MacPorts rust releases maybe his setup could be
helpful to the rest of us?

Ultimately the GitHub project that hosts the bootstrap binaries is
just a string in the Tcl and could be pointed at an "official"
MacPorts repo or my repo or a separate project or whatever we have to
do.

On Tue, Dec 13, 2022 at 9:57 AM Herby G  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/ ), 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 ) 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),
>  which is being hosted in MarcusCalhoun-Lopez's personal Github account ( 
> 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 , 
> 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
>  )
>
> David Gilman opened a PR recently attempting to update Rust to 1.64.0 ( 
> 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.



-- 
David Gilman
:DG<

The State of Rust in MacPorts Today

[Herby G]

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/ ), 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 ) 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),
which is being hosted in MarcusCalhoun-Lopez's personal Github account (
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 ,
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
)

David Gilman opened a PR recently attempting to update Rust to 1.64.0 (
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.