From hacking.johan at yahoo.com  Thu Dec  1 01:18:48 2022
From: hacking.johan at yahoo.com (Johan Ceuppens)
Date: Thu, 1 Dec 2022 02:18:48 +0100
Subject: libpicwords addition
References: <74EA7C7F-204F-4FC4-9C4F-139A0C91DA04.ref@yahoo.com>
Message-ID: <74EA7C7F-204F-4FC4-9C4F-139A0C91DA04@yahoo.com>

Hi,

I am making a small picture library for rendering on a frame buffer, such as a devkitpro PPC client or a Gameboy or of course anything virtual frame buffered. It stores bitmap matrices and blits them to the fb.

I would like to add it to the ports tree, while it is still in development.

I wanted to submit a game but I finally managed to make a portable library for graphics.

Here?s the source code : https://sourceforge.net/projects/libpicwords/files/

Tell me what you think.
Johan

Sent from my iPod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221201/474f2f24/attachment.htm>

From ryandesign at macports.org  Thu Dec  1 13:05:42 2022
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 1 Dec 2022 07:05:42 -0600
Subject: Request to re-run buildbots for a few ports
In-Reply-To: <CD5CE0E2-01F3-4F94-B0EF-9DFAFD303EF1@korins.ky>
References: <CD5CE0E2-01F3-4F94-B0EF-9DFAFD303EF1@korins.ky>
Message-ID: <A9508091-1AB0-40E6-A661-F64557CCC266@macports.org>

On Nov 28, 2022, at 14:34, Kirill A. Korinsky wrote:

> May I ask anyone with access to reschedule build for ports: scalapack and papilo?

Jeremy scheduled a rebuild of scalapack on 10.7 which succeeded. Looks like it had already succeeded on the other workers before.

I scheduled a rebuild of papilo on all workers. It failed on 10.6 because its dependency onetbb fails there. It succeeded on 10.9. The build on 10.8 should start soon. Looks like it already succeeded on the other workers before.


From kirill at korins.ky  Thu Dec  1 14:17:04 2022
From: kirill at korins.ky (Kirill A. Korinsky)
Date: Thu, 1 Dec 2022 15:17:04 +0100
Subject: Request to re-run buildbots for a few ports
In-Reply-To: <A9508091-1AB0-40E6-A661-F64557CCC266@macports.org>
References: <CD5CE0E2-01F3-4F94-B0EF-9DFAFD303EF1@korins.ky>
 <A9508091-1AB0-40E6-A661-F64557CCC266@macports.org>
Message-ID: <3ACDA0D1-C067-4F85-AC20-23D1D4E108BA@korins.ky>

Thanks.

Fixing OneTBB on 10.6

--
wbr, Kirill

> On 1. Dec 2022, at 14:05, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Nov 28, 2022, at 14:34, Kirill A. Korinsky wrote:
> 
>> May I ask anyone with access to reschedule build for ports: scalapack and papilo?
> 
> Jeremy scheduled a rebuild of scalapack on 10.7 which succeeded. Looks like it had already succeeded on the other workers before.
> 
> I scheduled a rebuild of papilo on all workers. It failed on 10.6 because its dependency onetbb fails there. It succeeded on 10.9. The build on 10.8 should start soon. Looks like it already succeeded on the other workers before.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221201/84ab42df/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221201/84ab42df/attachment.sig>

From vital.had at gmail.com  Sun Dec  4 05:21:01 2022
From: vital.had at gmail.com (Sergio Had)
Date: Sun, 4 Dec 2022 13:21:01 +0800
Subject: Implementing R packages via ports
In-Reply-To: <e8d20a0b-d5c6-40e6-97cc-25d0259bd86e@Spark>
References: <e8d20a0b-d5c6-40e6-97cc-25d0259bd86e@Spark>
Message-ID: <879c72b1-bd0c-4003-bd9c-f587f73fbe18@Spark>

Are there some non-obvious reasons not to have ports for R packages? Or just no one felt like making any?

R basically uses a mechanism akin to Python, OCaml or Perl, installing stuff into its ?mini-prefix?. While we do have ports for the latter three (not many for OCaml), there are none for R.
FreeBSD at the same time does have ports for select R packages.

Why bother?

1. Some packages are broken for old systems (including Intel), but can be trivially fixed with patches. Those include some basic packages, like fs and xml2.
2. In a number of cases all that is needed is legacysupport PG.
3. With a fancy complicated packages we may prefer using existing dependencies rather than building supplied ? usually outdated ? duplicate copies. (At least for testing/development.)

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221204/04341b88/attachment.htm>

From kirill at korins.ky  Wed Dec  7 12:45:10 2022
From: kirill at korins.ky (Kirill A. Korinsky)
Date: Wed, 7 Dec 2022 13:45:10 +0100
Subject: Allow installing both port:tbb and port:onetbb
Message-ID: <F9684210-BDED-46EE-B2FB-06D4ED10E835@korins.ky>

Folks,

I'd like to announce the PR on which I've worked for last weeks.

The goal is allow to install both `tbb` and `onetbb` port on the same machine, and it forces to add installing both `oce` and `opencascade`.

It is based on serveral PRs which I've made and which's fixed broken ports:
 - https://github.com/macports/macports-ports/pull/16866
 - https://github.com/macports/macports-ports/pull/16876
 - https://github.com/macports/macports-ports/pull/16888
 - https://github.com/macports/macports-ports/pull/16893
 - https://github.com/macports/macports-ports/pull/16899
 - https://github.com/macports/macports-ports/pull/16912

If someone with write access can review and merge one of dependant ports, I'll be very appreciated.

--
wbr, Kirill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221207/b981b84b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221207/b981b84b/attachment.sig>

From ken.cunningham.webuse at gmail.com  Sat Dec 10 17:57:38 2022
From: ken.cunningham.webuse at gmail.com (Ken Cunningham)
Date: Sat, 10 Dec 2022 09:57:38 -0800
Subject: Refined Github
Message-ID: <57CC170C-A391-4F2A-A98A-140F75AF1163@gmail.com>

For anyone who uses GitHub a lot, like the people on this list likely do, I came across Refined Github a few months ago, and I find it is quite helpful.

It?s browser extension that adds considerable functionality to Github, basically.

Thought I?d share:

https://github.com/refined-github/refined-github


K

From steve.t.smith at gmail.com  Sun Dec 11 15:34:14 2022
From: steve.t.smith at gmail.com (Steven Smith)
Date: Sun, 11 Dec 2022 10:34:14 -0500
Subject: ImageMagick Upgrade to version 7.1.0-54 Hitting OpenCL ld errors
Message-ID: <BF64E1EA-FE27-451B-986D-AA2FBF82E7EB@gmail.com>

I?m trying to upgrade the ImageMagick Portfile to version 7.1.0-54 and am hitting linker errors with OpenCL.

I see that homebrew has a working version at https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb <https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb>, so I?ve tried to make sure I?ve copies their setup, but am still hitting this issue, observed a year ago here, https://trac.macports.org/ticket/64087 <https://trac.macports.org/ticket/64087>.

Does anyone have a suggestion for locating these symbols?

> :info:build libtool: link: /usr/bin/clang -dynamiclib  -o MagickCore/.libs/libMagickCore-7.Q16.10.dylib  MagickCore/.libs/libMagickCore_7_Q16_la-accelerate.o  ? MagickCore/.libs/libMagickCore_7_Q16_la-xwindow.o   -L/opt/local/lib -L/opt/local/lib/libomp -lomp -llcms2 -lxml2 -lfontconfig -lfreetype -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lzip -lltdl -lm -lpthread  -Os -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64   -pthread -install_name  /opt/local/lib/libMagickCore-7.Q16.10.dylib -compatibility_version 11 -current_version 11.0 -Wl,-single_module
> :info:build ld: warning: directory not found for option '-L/opt/local/lib/ImageMagick-7.1.0'
> :info:build Undefined symbols for architecture x86_64:
> :info:build   "_clBuildProgram", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clCreateBuffer", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clCreateCommandQueue", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clCreateContext", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clCreateKernel", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clCreateProgramWithBinary", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clCreateProgramWithSource", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clEnqueueMapBuffer", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clEnqueueNDRangeKernel", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> :info:build   "_clEnqueueReadBuffer", referenced from:
> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221211/d1464a12/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4422 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221211/d1464a12/attachment.bin>

From jmr at macports.org  Sun Dec 11 15:54:50 2022
From: jmr at macports.org (Joshua Root)
Date: Mon, 12 Dec 2022 02:54:50 +1100
Subject: ImageMagick Upgrade to version 7.1.0-54 Hitting OpenCL ld errors
In-Reply-To: <BF64E1EA-FE27-451B-986D-AA2FBF82E7EB@gmail.com>
References: <BF64E1EA-FE27-451B-986D-AA2FBF82E7EB@gmail.com>
Message-ID: <399f3891-29bc-2376-d547-3e6b4d3cf604@macports.org>

Those are OpenCL functions, so you'd normally link with '-framework 
OpenCL' to get them. I notice the brew formula configures with 
--disable-opencl.

- Josh

On 2022-12-12 02:34 , Steven Smith wrote:
> I?m trying to upgrade the ImageMagick Portfile to version 7.1.0-54 and 
> am hitting linker errors with OpenCL.
> 
> I see that homebrew has a working version at 
> https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb <https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb>, so I?ve tried to make sure I?ve copies their setup, but am still hitting this issue, observed a year ago here, https://trac.macports.org/ticket/64087 <https://trac.macports.org/ticket/64087>.
> 
> Does anyone have a suggestion for locating these symbols?
> 
>> :info:build libtool: link: /usr/bin/clang 
>> -dynamiclib??-o?MagickCore/.libs/libMagickCore-7.Q16.10.dylib??MagickCore/.libs/libMagickCore_7_Q16_la-accelerate.o????MagickCore/.libs/libMagickCore_7_Q16_la-xwindow.o???-L/opt/local/lib -L/opt/local/lib/libomp -lomp -llcms2 -lxml2 -lfontconfig -lfreetype -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz?-lzip -lltdl -lm -lpthread??-Os -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch?x86_64???-pthread -install_name??/opt/local/lib/libMagickCore-7.Q16.10.dylib -compatibility_version 11 -current_version 11.0?-Wl,-single_module
>> :info:build ld: warning: directory not found for option 
>> '-L/opt/local/lib/ImageMagick-7.1.0'
>> :info:build Undefined symbols for architecture x86_64:
>> :info:build???"_clBuildProgram", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clCreateBuffer", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clCreateCommandQueue", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clCreateContext", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clCreateKernel", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clCreateProgramWithBinary", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clCreateProgramWithSource", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clEnqueueMapBuffer", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clEnqueueNDRangeKernel", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>> :info:build???"_clEnqueueReadBuffer", referenced from:
>> :info:build?? ? ??_InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> 


From steve.t.smith at gmail.com  Sun Dec 11 15:57:48 2022
From: steve.t.smith at gmail.com (Steven Smith)
Date: Sun, 11 Dec 2022 10:57:48 -0500
Subject: ImageMagick Upgrade to version 7.1.0-54 Hitting OpenCL ld errors
In-Reply-To: <399f3891-29bc-2376-d547-3e6b4d3cf604@macports.org>
References: <BF64E1EA-FE27-451B-986D-AA2FBF82E7EB@gmail.com>
 <399f3891-29bc-2376-d547-3e6b4d3cf604@macports.org>
Message-ID: <7ECCD371-4582-43E8-A5D1-0FF5B1793717@gmail.com>

Thanks,

I used --disable-opencl but see that the Portfile enables it elsewhere. Fixed now and working. I?ll issue a PR.

Perhaps a good idea to disable OpenCL: https://discussions.apple.com/thread/254008829

> On Dec 11, 2022, at 10:54 AM, Joshua Root <jmr at macports.org> wrote:
> 
> Those are OpenCL functions, so you'd normally link with '-framework OpenCL' to get them. I notice the brew formula configures with --disable-opencl.
> 
> - Josh
> 
> On 2022-12-12 02:34 , Steven Smith wrote:
>> I?m trying to upgrade the ImageMagick Portfile to version 7.1.0-54 and am hitting linker errors with OpenCL.
>> I see that homebrew has a working version at https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb <https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb>, so I?ve tried to make sure I?ve copies their setup, but am still hitting this issue, observed a year ago here, https://trac.macports.org/ticket/64087 <https://trac.macports.org/ticket/64087>.
>> Does anyone have a suggestion for locating these symbols?
>>> :info:build libtool: link: /usr/bin/clang -dynamiclib  -o MagickCore/.libs/libMagickCore-7.Q16.10.dylib  MagickCore/.libs/libMagickCore_7_Q16_la-accelerate.o  ? MagickCore/.libs/libMagickCore_7_Q16_la-xwindow.o   -L/opt/local/lib -L/opt/local/lib/libomp -lomp -llcms2 -lxml2 -lfontconfig -lfreetype -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lzip -lltdl -lm -lpthread  -Os -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64   -pthread -install_name  /opt/local/lib/libMagickCore-7.Q16.10.dylib -compatibility_version 11 -current_version 11.0 -Wl,-single_module
>>> :info:build ld: warning: directory not found for option '-L/opt/local/lib/ImageMagick-7.1.0'
>>> :info:build Undefined symbols for architecture x86_64:
>>> :info:build   "_clBuildProgram", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clCreateBuffer", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clCreateCommandQueue", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clCreateContext", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clCreateKernel", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clCreateProgramWithBinary", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clCreateProgramWithSource", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clEnqueueMapBuffer", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clEnqueueNDRangeKernel", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
>>> :info:build   "_clEnqueueReadBuffer", referenced from:
>>> :info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4422 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221211/ae7ff414/attachment-0001.bin>

From watsonbladd at gmail.com  Mon Dec 12 15:35:17 2022
From: watsonbladd at gmail.com (Watson Ladd)
Date: Mon, 12 Dec 2022 10:35:17 -0500
Subject: Dev guide updated for github/easy instructions?
Message-ID: <CACsn0cnRMbRfUfxkJAv8hmDpAdk9nh4JtArnsc+aZh3eXGcAeA@mail.gmail.com>

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

From nils at breun.nl  Mon Dec 12 21:55:31 2022
From: nils at breun.nl (Nils Breunese)
Date: Mon, 12 Dec 2022 22:55:31 +0100
Subject: Dev guide updated for github/easy instructions?
In-Reply-To: <CACsn0cnRMbRfUfxkJAv8hmDpAdk9nh4JtArnsc+aZh3eXGcAeA@mail.gmail.com>
References: <CACsn0cnRMbRfUfxkJAv8hmDpAdk9nh4JtArnsc+aZh3eXGcAeA@mail.gmail.com>
Message-ID: <F451F3F9-2852-4EC0-AEF0-7732B9933697@breun.nl>

Does https://guide.macports.org/chunked/project.github.html help?

Nils.

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

> Op 12 dec. 2022, om 16:35 heeft Watson Ladd <watsonbladd at gmail.com> 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


From herby.gillot at gmail.com  Tue Dec 13 14:57:16 2022
From: herby.gillot at gmail.com (Herby G)
Date: Tue, 13 Dec 2022 09:57:16 -0500
Subject: The State of Rust in MacPorts Today
Message-ID: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/28d2a8ef/attachment.htm>

From davidgilman1 at gmail.com  Tue Dec 13 15:22:30 2022
From: davidgilman1 at gmail.com (David Gilman)
Date: Tue, 13 Dec 2022 10:22:30 -0500
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
Message-ID: <CALBH9DCi-G7SohzR21EUK+p4MU8xz_L-DbssiAzQ4RHKK98_Og@mail.gmail.com>

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 <herby.gillot at gmail.com> 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<

From jonesc at hep.phy.cam.ac.uk  Tue Dec 13 15:49:48 2022
From: jonesc at hep.phy.cam.ac.uk (Christopher Jones)
Date: Tue, 13 Dec 2022 15:49:48 +0000
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
Message-ID: <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>

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 <herby.gillot at gmail.com> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/262bd257/attachment-0001.htm>

From kirill at korins.ky  Tue Dec 13 16:07:15 2022
From: kirill at korins.ky (Kirill A. Korinsky)
Date: Tue, 13 Dec 2022 17:07:15 +0100
Subject: The State of Rust in MacPorts Today
In-Reply-To: <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
Message-ID: <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>

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 <jonesc at hep.phy.cam.ac.uk> 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 <herby.gillot at gmail.com <mailto:herby.gillot at gmail.com>> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/4a277d33/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/4a277d33/attachment.sig>

From stephen.langer at nist.gov  Tue Dec 13 16:09:23 2022
From: stephen.langer at nist.gov (Langer, Stephen A. (Fed))
Date: Tue, 13 Dec 2022 16:09:23 +0000
Subject: Dev guide updated for github/easy instructions?
In-Reply-To: <F451F3F9-2852-4EC0-AEF0-7732B9933697@breun.nl>
References: <CACsn0cnRMbRfUfxkJAv8hmDpAdk9nh4JtArnsc+aZh3eXGcAeA@mail.gmail.com>
 <F451F3F9-2852-4EC0-AEF0-7732B9933697@breun.nl>
Message-ID: <MN2PR09MB5530E118B352E09255BE4721E6E39@MN2PR09MB5530.namprd09.prod.outlook.com>

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

-- Steve

From: macports-dev <macports-dev-bounces at lists.macports.org> on behalf of Nils Breunese <nils at breun.nl>
Date: Monday, December 12, 2022 at 4:56 PM
To: MacPorts Development <macports-dev at lists.macports.org>
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-dev at lists.macosforge.org is the old address of this mailing list, macports-dev at lists.macports.org is the new one.

> Op 12 dec. 2022, om 16:35 heeft Watson Ladd <watsonbladd at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/652b7638/attachment-0001.htm>

From vital.had at gmail.com  Tue Dec 13 16:29:23 2022
From: vital.had at gmail.com (Sergio Had)
Date: Tue, 13 Dec 2022 23:29:23 +0700
Subject: The State of Rust in MacPorts Today
In-Reply-To: <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
Message-ID: <dc1a7335-f64d-4e75-9c7e-6f6cb33b5ec1@Spark>

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 <macports-dev at 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 <jonesc at hep.phy.cam.ac.uk> 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 <herby.gillot at gmail.com> 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/548cfbda/attachment.htm>

From davidgilman1 at gmail.com  Tue Dec 13 16:53:13 2022
From: davidgilman1 at gmail.com (David Gilman)
Date: Tue, 13 Dec 2022 11:53:13 -0500
Subject: The State of Rust in MacPorts Today
In-Reply-To: <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
Message-ID: <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>

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 at 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 <jonesc at hep.phy.cam.ac.uk>
> 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 <herby.gillot at gmail.com> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/65ee5e74/attachment-0001.htm>

From kirill at korins.ky  Tue Dec 13 17:07:20 2022
From: kirill at korins.ky (Kirill A. Korinsky)
Date: Tue, 13 Dec 2022 18:07:20 +0100
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
Message-ID: <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>

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 <davidgilman1 at gmail.com> 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 at lists.macports.org <mailto:macports-dev at 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/ <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 <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> 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 <herby.gillot at gmail.com <mailto:herby.gillot at gmail.com>> 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.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/b959b5c7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/b959b5c7/attachment.sig>

From jonesc at hep.phy.cam.ac.uk  Tue Dec 13 17:16:28 2022
From: jonesc at hep.phy.cam.ac.uk (Christopher Jones)
Date: Tue, 13 Dec 2022 17:16:28 +0000
Subject: The State of Rust in MacPorts Today
In-Reply-To: <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
 <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
Message-ID: <0602737F-95BF-414E-8FBE-C7511CE126A8@hep.phy.cam.ac.uk>

Hi,

> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev <macports-dev at 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 <davidgilman1 at gmail.com <mailto:davidgilman1 at gmail.com>> 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 at lists.macports.org <mailto:macports-dev at 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/ <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 <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> 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 <herby.gillot at gmail.com <mailto:herby.gillot at gmail.com>> 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.
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/3b258658/attachment-0001.htm>

From kirill at korins.ky  Tue Dec 13 17:21:04 2022
From: kirill at korins.ky (Kirill A. Korinsky)
Date: Tue, 13 Dec 2022 18:21:04 +0100
Subject: The State of Rust in MacPorts Today
In-Reply-To: <0602737F-95BF-414E-8FBE-C7511CE126A8@hep.phy.cam.ac.uk>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
 <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
 <0602737F-95BF-414E-8FBE-C7511CE126A8@hep.phy.cam.ac.uk>
Message-ID: <922D6A81-7236-419A-B860-406258D31927@korins.ky>

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 <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> Hi,
> 
>> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev <macports-dev at lists.macports.org <mailto:macports-dev at 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 <davidgilman1 at gmail.com <mailto:davidgilman1 at gmail.com>> 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 at lists.macports.org <mailto:macports-dev at 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/ <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 <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> 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 <herby.gillot at gmail.com <mailto:herby.gillot at gmail.com>> 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.
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/1a247fec/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/1a247fec/attachment-0001.sig>

From artkiver at gmail.com  Tue Dec 13 17:32:13 2022
From: artkiver at gmail.com (grey)
Date: Tue, 13 Dec 2022 17:32:13 +0000
Subject: The State of Rust in MacPorts Today
In-Reply-To: <922D6A81-7236-419A-B860-406258D31927@korins.ky>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
 <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
 <0602737F-95BF-414E-8FBE-C7511CE126A8@hep.phy.cam.ac.uk>
 <922D6A81-7236-419A-B860-406258D31927@korins.ky>
Message-ID: <CA+fPMHHtR6bzwJB29tpZ-qwQLAMd+b5Kdp3SbGBk_yb6eRBcrg@mail.gmail.com>

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
<macports-dev at lists.macports.org> 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 <jonesc at hep.phy.cam.ac.uk> wrote:
>
> Hi,
>
> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev <macports-dev at 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 <davidgilman1 at gmail.com> 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 at 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 <jonesc at hep.phy.cam.ac.uk> 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 <herby.gillot at gmail.com> 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.
>>
>>
>>
>
>
>

From vital.had at gmail.com  Tue Dec 13 19:23:57 2022
From: vital.had at gmail.com (Sergey Fedorov)
Date: Wed, 14 Dec 2022 02:23:57 +0700
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CA+fPMHHtR6bzwJB29tpZ-qwQLAMd+b5Kdp3SbGBk_yb6eRBcrg@mail.gmail.com>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
 <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
 <0602737F-95BF-414E-8FBE-C7511CE126A8@hep.phy.cam.ac.uk>
 <922D6A81-7236-419A-B860-406258D31927@korins.ky>
 <CA+fPMHHtR6bzwJB29tpZ-qwQLAMd+b5Kdp3SbGBk_yb6eRBcrg@mail.gmail.com>
Message-ID: <CALYdzyn19m9jtFqofHYLmtNoBDiY=Ugbadg5hwuhuFg4F6QyEQ@mail.gmail.com>

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 <artkiver at gmail.com> 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
> <macports-dev at lists.macports.org> 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 <jonesc at hep.phy.cam.ac.uk>
> wrote:
> >
> > Hi,
> >
> > On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev <
> macports-dev at 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 <davidgilman1 at gmail.com> 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 at 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 <jonesc at hep.phy.cam.ac.uk>
> 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 <herby.gillot at gmail.com> 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.
> >>
> >>
> >>
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221214/db7b3dc5/attachment-0001.htm>

From dave.allured at noaa.gov  Tue Dec 13 21:27:04 2022
From: dave.allured at noaa.gov (Dave Allured - NOAA Affiliate)
Date: Tue, 13 Dec 2022 16:27:04 -0500
Subject: The State of Rust in MacPorts Today
In-Reply-To: <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
 <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
Message-ID: <CALqwTFNyuHYSrCawucKOXvUtfkSuOF77ZEmJt2uDwLFc8yy35A@mail.gmail.com>

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 at 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 <davidgilman1 at gmail.com> 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 at 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 <jonesc at hep.phy.cam.ac.uk>
>> 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 <herby.gillot at gmail.com> 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.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/35ac6f75/attachment.htm>

From kirill at korins.ky  Tue Dec 13 21:33:35 2022
From: kirill at korins.ky (Kirill A. Korinsky)
Date: Tue, 13 Dec 2022 22:33:35 +0100
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CALqwTFNyuHYSrCawucKOXvUtfkSuOF77ZEmJt2uDwLFc8yy35A@mail.gmail.com>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <E4248FD1-85EA-42B9-885C-3CF9720335C5@korins.ky>
 <CALBH9DBmr4aH_zvhORNRineh5twDzk333aHOBDkoRE-CKWaY6g@mail.gmail.com>
 <957DE623-E2CB-4FF4-9116-35547056A381@korins.ky>
 <CALqwTFNyuHYSrCawucKOXvUtfkSuOF77ZEmJt2uDwLFc8yy35A@mail.gmail.com>
Message-ID: <7B5F3A9E-3AB7-47A4-AA37-70FF642C0390@korins.ky>

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 <macports-dev at lists.macports.org> 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 <macports-dev at lists.macports.org <mailto:macports-dev at 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 <davidgilman1 at gmail.com <mailto:davidgilman1 at gmail.com>> 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 at lists.macports.org <mailto:macports-dev at 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/ <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 <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> 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 <herby.gillot at gmail.com <mailto:herby.gillot at gmail.com>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/bbc66db6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/bbc66db6/attachment-0001.sig>

From kpreid at switchb.org  Wed Dec 14 01:30:34 2022
From: kpreid at switchb.org (Kevin Reid)
Date: Tue, 13 Dec 2022 17:30:34 -0800
Subject: The State of Rust in MacPorts Today
In-Reply-To: <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
Message-ID: <CANkSj9Vy99HOQ3H80Sb3HHX-vp6sjkHSK_ech_ZQAq7oz_HYMQ@mail.gmail.com>

On Tue, Dec 13, 2022 at 7:50 AM Christopher Jones <jonesc at hep.phy.cam.ac.uk>
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
<https://rust-lang.github.io/rustup/overrides.html> [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
<https://rust-lang.github.io/rustup/installation/package-managers.html> [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221213/6e07b356/attachment.htm>

From herby.gillot at gmail.com  Thu Dec 15 23:34:08 2022
From: herby.gillot at gmail.com (Herby G)
Date: Thu, 15 Dec 2022 18:34:08 -0500
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CANkSj9Vy99HOQ3H80Sb3HHX-vp6sjkHSK_ech_ZQAq7oz_HYMQ@mail.gmail.com>
References: <CAHbmUeTZBrJtezTOE4b3Y4jLQTqzq0PtghskAtyhbtHY3n7Fxg@mail.gmail.com>
 <F4469945-677A-47D2-B0F2-C6A607D6FD63@hep.phy.cam.ac.uk>
 <CANkSj9Vy99HOQ3H80Sb3HHX-vp6sjkHSK_ech_ZQAq7oz_HYMQ@mail.gmail.com>
Message-ID: <CAHbmUeQsH2xKXGMTe5QH0vVMur95i4KFwXRXPwgpXm=DxssU8Q@mail.gmail.com>

Kevin Reid:

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

A very solid idea. We need to focus on getting the rust-N ports into place
to start.

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

Do you need the older macOS environments just to test the Rust update, or
do you need them to build the bootstrap compilers for these environments?

Because if it's the former, then I think we should just move forward using
the buildbots.  We need to get the Rust 1.(X-1) bootstrap compilers built
and hosted somewhere, then verify that the latest Rust (1.66.0 as of now)
can be built in Github CI.  Once that works, we should just commit the
update and observe via buildbot status which macOS versions are failing,
and do our best to resolve each broken environment over time.

At this point, upgrading incrementally across environments makes more sense
than trying to verify it works in every single environment before updating.

On Tue, Dec 13, 2022 at 8:31 PM Kevin Reid <kpreid at switchb.org> wrote:

> On Tue, Dec 13, 2022 at 7:50 AM Christopher Jones <
> jonesc at hep.phy.cam.ac.uk> 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
> <https://rust-lang.github.io/rustup/overrides.html> [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
> <https://rust-lang.github.io/rustup/installation/package-managers.html> [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221215/3ca42e56/attachment.htm>

From ken.cunningham.webuse at gmail.com  Sun Dec 18 23:35:40 2022
From: ken.cunningham.webuse at gmail.com (Ken Cunningham)
Date: Sun, 18 Dec 2022 15:35:40 -0800
Subject: The State of Rust in MacPorts Today
Message-ID: <28CD6D3F-79F0-4040-B339-555D8FA52232@gmail.com>

It looks like Marcus is working on this.

K

From watsonbladd at gmail.com  Mon Dec 19 15:04:56 2022
From: watsonbladd at gmail.com (Watson Ladd)
Date: Mon, 19 Dec 2022 07:04:56 -0800
Subject: Dev guide updated for github/easy instructions?
In-Reply-To: <F451F3F9-2852-4EC0-AEF0-7732B9933697@breun.nl>
References: <CACsn0cnRMbRfUfxkJAv8hmDpAdk9nh4JtArnsc+aZh3eXGcAeA@mail.gmail.com>
 <F451F3F9-2852-4EC0-AEF0-7732B9933697@breun.nl>
Message-ID: <CACsn0cm91T1k03upE21hW7yCwYNFYXns4dSusV9KYHe1uJty7Q@mail.gmail.com>

On Mon, Dec 12, 2022, 1:55 PM Nils Breunese <nils at breun.nl> wrote:

> Does https://guide.macports.org/chunked/project.github.html help?
>

A bit. What I don't know how to do is get macports to use the modified port
file. The best I can figure out is use the whole different tree, which is
mildly annoying if I forget to set it back.

>
> Nils.
>
> P.S. I believe macports-dev at lists.macosforge.org is the old address of
> this mailing list, macports-dev at lists.macports.org is the new one.
>
> > Op 12 dec. 2022, om 16:35 heeft Watson Ladd <watsonbladd at gmail.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221219/dae70327/attachment.htm>

From ken.cunningham.webuse at gmail.com  Mon Dec 19 15:11:24 2022
From: ken.cunningham.webuse at gmail.com (Ken Cunningham)
Date: Mon, 19 Dec 2022 07:11:24 -0800
Subject: Dev guide updated for github/easy instructions?
In-Reply-To: <CACsn0cm91T1k03upE21hW7yCwYNFYXns4dSusV9KYHe1uJty7Q@mail.gmail.com>
References: <CACsn0cm91T1k03upE21hW7yCwYNFYXns4dSusV9KYHe1uJty7Q@mail.gmail.com>
Message-ID: <6900528C-BEB5-4262-BC9D-CF90ABBACD85@gmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221219/20138172/attachment.htm>

From mcalhoun at macports.org  Wed Dec 21 03:51:15 2022
From: mcalhoun at macports.org (mcalhoun at macports.org)
Date: Tue, 20 Dec 2022 20:51:15 -0700
Subject: The State of Rust in MacPorts Today
In-Reply-To: <28CD6D3F-79F0-4040-B339-555D8FA52232@gmail.com>
References: <28CD6D3F-79F0-4040-B339-555D8FA52232@gmail.com>
Message-ID: <E4F35586-9805-4755-9327-5ABF4FAE117F@macports.org>

I am sorry I have not been a better maintainer for the Rust port.
Life has been a little hectic.

As has been discussed in this thread, there is definitely room for improvements in the Rust setup.
Until a final consensus is reached, I opened a pull request to at least get Rust to its latest version using the previous infrastructure.
(https://github.com/macports/macports-ports/pull/17028).

I am not sure the GCC and Clang ports are necessary a good model.
In those cases, there is a system compiler could build a compiler, which could be used to build a compiler, etc.
That is not the case for Rust.

To build Rust, MacPorts has to download Rust binaries.
If the system is new enough, upstream provides them.
If we want to support older system, we have to build and distribute our own.
Of course, mrustc and/or Rust-GCC may change that.

If we do decide to continue our own Rust binaries, I agree that it would be highly advisable to find a more suitable location.

-Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221220/a81f0820/attachment.htm>

From herby.gillot at gmail.com  Wed Dec 21 04:53:57 2022
From: herby.gillot at gmail.com (Herby G)
Date: Tue, 20 Dec 2022 23:53:57 -0500
Subject: The State of Rust in MacPorts Today
In-Reply-To: <E4F35586-9805-4755-9327-5ABF4FAE117F@macports.org>
References: <28CD6D3F-79F0-4040-B339-555D8FA52232@gmail.com>
 <E4F35586-9805-4755-9327-5ABF4FAE117F@macports.org>
Message-ID: <CAHbmUeQf9Hz_WznmxKxoDvfYAqc-_PGFQP8ZaEms7=9utBYkEg@mail.gmail.com>

Thank you for the update, Marcus. I apologize for any harsh tone of mine in
this conversation, and I hope that things are getting better on your end.

I tested this PR on macOS 12.6.2 arm64 and it built successfully:

$ rustc --version; cargo --version
> rustc 1.66.0 (69f9c33d7 2022-12-12) (built from a source tarball)
> cargo 1.66.0
>

> If we do decide to continue our own Rust binaries, I agree that it would
be highly advisable to find a more suitable location.

Can we restart the discussion about placing this in an official repo in the
MacPorts Github account? Would also be nice to use Github actions to
automatically build as much as is possible in an automated way on update.


On Tue, Dec 20, 2022 at 10:51 PM <mcalhoun at macports.org> wrote:

> I am sorry I have not been a better maintainer for the Rust port.
> Life has been a little hectic.
>
> As has been discussed in this thread, there is definitely room for
> improvements in the Rust setup.
> Until a final consensus is reached, I opened a pull request to at least
> get Rust to its latest version using the previous infrastructure.
> (https://github.com/macports/macports-ports/pull/17028).
>
> I am not sure the GCC and Clang ports are necessary a good model.
> In those cases, there is a system compiler could build a compiler, which
> could be used to build a compiler, etc.
> That is not the case for Rust.
>
> To build Rust, MacPorts has to download Rust binaries.
> If the system is new enough, upstream provides them.
> If we want to support older system, we have to build and distribute our
> own.
> Of course, mrustc and/or Rust-GCC may change that.
>
> If we do decide to continue our own Rust binaries, I agree that it would
> be highly advisable to find a more suitable location.
>
> -Marcus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221220/5ab7b9e8/attachment.htm>

From mcalhoun at macports.org  Wed Dec 21 21:18:02 2022
From: mcalhoun at macports.org (mcalhoun at macports.org)
Date: Wed, 21 Dec 2022 14:18:02 -0700
Subject: The State of Rust in MacPorts Today
In-Reply-To: <CAHbmUeQf9Hz_WznmxKxoDvfYAqc-_PGFQP8ZaEms7=9utBYkEg@mail.gmail.com>
References: <28CD6D3F-79F0-4040-B339-555D8FA52232@gmail.com>
 <E4F35586-9805-4755-9327-5ABF4FAE117F@macports.org>
 <CAHbmUeQf9Hz_WznmxKxoDvfYAqc-_PGFQP8ZaEms7=9utBYkEg@mail.gmail.com>
Message-ID: <C26642E3-BD75-4B66-A75A-8601BA92D7B8@macports.org>

Thank you for your efforts to improve the Rust port.
I will ask on the mailing list about about moving the Rust binaries to a more suitable location.

-Marcus

> On Dec 20, 2022, at 9:53 PM, Herby G <herby.gillot at gmail.com> wrote:
> 
> Thank you for the update, Marcus. I apologize for any harsh tone of mine in this conversation, and I hope that things are getting better on your end.
> 
> I tested this PR on macOS 12.6.2 arm64 and it built successfully:
> 
>> $ rustc --version; cargo --version
>> rustc 1.66.0 (69f9c33d7 2022-12-12) (built from a source tarball)
>> cargo 1.66.0
> 
> > If we do decide to continue our own Rust binaries, I agree that it would be highly advisable to find a more suitable location.
> 
> Can we restart the discussion about placing this in an official repo in the MacPorts Github account? Would also be nice to use Github actions to automatically build as much as is possible in an automated way on update.
> 
> 
> On Tue, Dec 20, 2022 at 10:51 PM <mcalhoun at macports.org <mailto:mcalhoun at macports.org>> wrote:
>> I am sorry I have not been a better maintainer for the Rust port.
>> Life has been a little hectic.
>> 
>> As has been discussed in this thread, there is definitely room for improvements in the Rust setup.
>> Until a final consensus is reached, I opened a pull request to at least get Rust to its latest version using the previous infrastructure.
>> (https://github.com/macports/macports-ports/pull/17028).
>> 
>> I am not sure the GCC and Clang ports are necessary a good model.
>> In those cases, there is a system compiler could build a compiler, which could be used to build a compiler, etc.
>> That is not the case for Rust.
>> 
>> To build Rust, MacPorts has to download Rust binaries.
>> If the system is new enough, upstream provides them.
>> If we want to support older system, we have to build and distribute our own.
>> Of course, mrustc and/or Rust-GCC may change that.
>> 
>> If we do decide to continue our own Rust binaries, I agree that it would be highly advisable to find a more suitable location.
>> 
>> -Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221221/c2b2ca18/attachment.htm>

From mcalhoun at macports.org  Thu Dec 22 04:02:20 2022
From: mcalhoun at macports.org (mcalhoun at macports.org)
Date: Wed, 21 Dec 2022 21:02:20 -0700
Subject: Location to store Rust binaries
Message-ID: <D3DF531E-24BA-41DE-91B8-D0A98F316B40@macports.org>

As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.

To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
Currently, these binaries are stored on using my personal GitHub account.

So the entire upgrade process is essentially:
1) Update the version in rust-bootstrap.
2) Build Rust binaries on a 10.9 VM.
3) Upload Rust binaries to GitHub account.
4) On older machines, use MacPorts Rust binaries to build Rust.
    On newer machines, us the upstream provides binaries to build Rust.

This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).

This entire procedure may be modified, and there are a few suggestions on the mailing list
(https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).

However, until consensus is reached about major changes, it would be nice to make some incremental improvements.

The easiest change: does anyone know of a better place to store the MacPorts generated binaries?

More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?

-Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221221/2fc130aa/attachment.htm>

From jonesc at hep.phy.cam.ac.uk  Thu Dec 22 09:30:19 2022
From: jonesc at hep.phy.cam.ac.uk (Chris Jones)
Date: Thu, 22 Dec 2022 09:30:19 +0000
Subject: Location to store Rust binaries
In-Reply-To: <D3DF531E-24BA-41DE-91B8-D0A98F316B40@macports.org>
References: <D3DF531E-24BA-41DE-91B8-D0A98F316B40@macports.org>
Message-ID: <6F6F0E8A-2F7C-418B-99C0-C652926BAE11@hep.phy.cam.ac.uk>



> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
> 
> ?
> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
> 
> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
> Currently, these binaries are stored on using my personal GitHub account.
> 
> So the entire upgrade process is essentially:
> 1) Update the version in rust-bootstrap.
> 2) Build Rust binaries on a 10.9 VM.
> 3) Upload Rust binaries to GitHub account.
> 4) On older machines, use MacPorts Rust binaries to build Rust.
>     On newer machines, us the upstream provides binaries to build Rust.
> 
> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
> 
> This entire procedure may be modified, and there are a few suggestions on the mailing list
> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
> 
> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
> 
> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
> 
> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?

I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?

Chris

> 
> -Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/e1d28a0f/attachment.htm>

From ken.cunningham.webuse at gmail.com  Thu Dec 22 13:02:33 2022
From: ken.cunningham.webuse at gmail.com (Ken Cunningham)
Date: Thu, 22 Dec 2022 05:02:33 -0800
Subject: Location to store Rust binaries
In-Reply-To: <6F6F0E8A-2F7C-418B-99C0-C652926BAE11@hep.phy.cam.ac.uk>
References: <6F6F0E8A-2F7C-418B-99C0-C652926BAE11@hep.phy.cam.ac.uk>
Message-ID: <ED31A084-0630-44E5-A43B-C5DA2B518004@gmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/a4a49439/attachment.htm>

From ken.cunningham.webuse at gmail.com  Thu Dec 22 13:13:03 2022
From: ken.cunningham.webuse at gmail.com (Ken Cunningham)
Date: Thu, 22 Dec 2022 05:13:03 -0800
Subject: Location to store Rust binaries
In-Reply-To: <ED31A084-0630-44E5-A43B-C5DA2B518004@gmail.com>
References: <ED31A084-0630-44E5-A43B-C5DA2B518004@gmail.com>
Message-ID: <4A33339A-9769-44DB-BCF7-3B831C5DD19B@gmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/b4b372a8/attachment-0001.htm>

From mcalhoun at macports.org  Thu Dec 22 13:28:13 2022
From: mcalhoun at macports.org (mcalhoun at macports.org)
Date: Thu, 22 Dec 2022 06:28:13 -0700
Subject: Location to store Rust binaries
In-Reply-To: <6F6F0E8A-2F7C-418B-99C0-C652926BAE11@hep.phy.cam.ac.uk>
References: <D3DF531E-24BA-41DE-91B8-D0A98F316B40@macports.org>
 <6F6F0E8A-2F7C-418B-99C0-C652926BAE11@hep.phy.cam.ac.uk>
Message-ID: <D381A7E2-CB77-4AFD-B92D-3930A9379D12@macports.org>

Please forgive me if I am misunderstanding your question.
As Ken pointed out, the rust-bootstrap binaries are generated just fine.
I suppose it might be possible to include https://packages.macports.org/ in the `master_sites` of the Rust port.
I am afraid I would have to thing about that a little.

-Marcus

> On Dec 22, 2022, at 2:30 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> 
> 
>> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
>> 
>> ?
>> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
>> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
>> 
>> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
>> Currently, these binaries are stored on using my personal GitHub account.
>> 
>> So the entire upgrade process is essentially:
>> 1) Update the version in rust-bootstrap.
>> 2) Build Rust binaries on a 10.9 VM.
>> 3) Upload Rust binaries to GitHub account.
>> 4) On older machines, use MacPorts Rust binaries to build Rust.
>>     On newer machines, us the upstream provides binaries to build Rust.
>> 
>> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
>> 
>> This entire procedure may be modified, and there are a few suggestions on the mailing list
>> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
>> 
>> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
>> 
>> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
>> 
>> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
> 
> I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?
> 
> Chris
> 
>> 
>> -Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/c397e9c9/attachment.htm>

From mcalhoun at macports.org  Thu Dec 22 13:31:49 2022
From: mcalhoun at macports.org (mcalhoun at macports.org)
Date: Thu, 22 Dec 2022 06:31:49 -0700
Subject: Location to store Rust binaries
In-Reply-To: <D3DF531E-24BA-41DE-91B8-D0A98F316B40@macports.org>
References: <D3DF531E-24BA-41DE-91B8-D0A98F316B40@macports.org>
Message-ID: <0145DE2C-7D5A-4F1B-9BC0-517B7D4CEAF4@macports.org>

I am sure everyone who cares about Rust is already familiar with the issues involved, but just for the sake of documentation, I will try to provide an overview.
The main issue is that a Rust compiler is required to build a Rust compiler.

On an Apple silicon machine running macOS 13, the Rust Portfile version 1.66 downloads
    rustc-1.65.0-aarch64-apple-darwin.tar.gz,
    rust-std-1.65.0-aarch64-apple-darwin.tar.gz, and
    cargo-1.65.0-aarch64-apple-darwin.tar.gz.
These are prebuilt binaries of the previous version (1.65) of the Rust compiler, Rust standard library, and Rust package manager respectively.
Upstream provides these prebuilt binaries for many different architectures [1].
This ?stage0 compiler? is then used to build a local copy of Rust [2].

The problem is that the upstream binaries will only run on macOS 10.9+.
Upstream says 10.7+, but that is just the language [3].
The combination of the language, standard library, and package manager make the minimum higher [4][5].
Also, there is a proposal to set the minimum supported version to 10.12 [6].

So the question is how to get a working stage0 Rust compiler on older systems?
*) The alternative Rust compilers gccrs is still ?in a very early stage? [7].
*) Mutabah's Rust Compiler (mrustc) is a Rust compiler written in C++ [8], so it may be a viable choice.
    However mrustc can build Rust up to 1.55, so, as pointed out by Kirill in another thread [10], the dependency chain could get quite long.
    If possible, it would be nice to avoid a similar issue with Clang [11].
*) There does not seem to be much enthusiasm upstream for re-adding support for older systems [6][12].
*) Previous versions of the Rust Portfile tried to modify the upstream binaries to work on older systems [13].
    This strategy certainly worked but could only go so far.

The current strategy is to build our own stag0 compiler in the port rust-bootstrap.
A 10.9+ machine builds the stage0 compiler.
The stage0 compiler is uploaded somewhere (currently my personal GitHub repository).
10.5-10.8 machines then download the stage0 compiler from us instead of upstream.
Our stage0 compiler makes extensive use of the MacPorts ecosystem, so that is another reason upstream would unlikely be interested.

Sorry if this is clear to everyone, but it took me a while to wrap my head around, and I am sure there are subtleties I am missing.

-Marcus

[1] https://github.com/rust-lang/rust/blob/1.66.0/src/stage0.json
[2] https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#stages-of-bootstrapping
[3] https://doc.rust-lang.org/nightly/rustc/platform-support.html
[4] https://trac.macports.org/ticket/62639
[5] https://github.com/rust-lang/rust/issues/40481
[6] https://github.com/rust-lang/rust/pull/104385
[7] https://github.com/Rust-GCC/gccrs
[8] https://github.com/thepowersgang/mrustc
[9] https://github.com/thepowersgang/mrustc#progress
[10] https://lists.macports.org/pipermail/macports-dev/2022-December/044862.html
[11] https://trac.macports.org/ticket/66226
[12] https://github.com/rust-lang/rfcs/pull/2837
[13] https://github.com/macports/macports-ports/blob/a9e1c26f4967b89ba6d0e546d2507ccc91adc295/lang/rust/Portfile#L66

> On Dec 21, 2022, at 9:02 PM, mcalhoun at macports.org wrote:
> 
> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
> 
> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
> Currently, these binaries are stored on using my personal GitHub account.
> 
> So the entire upgrade process is essentially:
> 1) Update the version in rust-bootstrap.
> 2) Build Rust binaries on a 10.9 VM.
> 3) Upload Rust binaries to GitHub account.
> 4) On older machines, use MacPorts Rust binaries to build Rust.
>     On newer machines, us the upstream provides binaries to build Rust.
> 
> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
> 
> This entire procedure may be modified, and there are a few suggestions on the mailing list
> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
> 
> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
> 
> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
> 
> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
> 
> -Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/2757d306/attachment.htm>

From jonesc at hep.phy.cam.ac.uk  Thu Dec 22 16:28:13 2022
From: jonesc at hep.phy.cam.ac.uk (Chris Jones)
Date: Thu, 22 Dec 2022 16:28:13 +0000
Subject: Location to store Rust binaries
In-Reply-To: <D381A7E2-CB77-4AFD-B92D-3930A9379D12@macports.org>
References: <D381A7E2-CB77-4AFD-B92D-3930A9379D12@macports.org>
Message-ID: <0DD8EC83-63EC-4561-8783-FCC4A1C67924@hep.phy.cam.ac.uk>



> On 22 Dec 2022, at 1:28 pm, mcalhoun at macports.org wrote:
> 
> ?
> Please forgive me if I am misunderstanding your question.
> As Ken pointed out, the rust-bootstrap binaries are generated just fine.
> I suppose it might be possible to include https://packages.macports.org/ in the `master_sites` of the Rust port.
> I am afraid I would have to thing about that a little.

My question is simply I am not getting what the reason is why you cannot make rust depend on rust-bootstrap when it needs to, on older systems, as a standard port dependency. Does *all* older systems have to use the binaries built on 10.9, or can rust-bootstrap be built fine as a port in 10.8, 10.7 etc. as well ?

Even if the answer to that last question is yes, only the 10.9 binaries can be used, I still feel like something custom could be done to allow the use of the standard binary tarball port distribution, so yes packages.macports.org, to distribute the 10.9 binaries of rust-bootstrap to all builds that need it. Basically, I see no need to use any other binary distribution infrastructure than the one we are already using for the regular binary tarballs.

Cheers Chris

> 
> -Marcus
> 
>>> On Dec 22, 2022, at 2:30 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>> 
>>> 
>>> 
>>>> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
>>>> 
>>> ?
>>> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
>>> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
>>> 
>>> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
>>> Currently, these binaries are stored on using my personal GitHub account.
>>> 
>>> So the entire upgrade process is essentially:
>>> 1) Update the version in rust-bootstrap.
>>> 2) Build Rust binaries on a 10.9 VM.
>>> 3) Upload Rust binaries to GitHub account.
>>> 4) On older machines, use MacPorts Rust binaries to build Rust.
>>>     On newer machines, us the upstream provides binaries to build Rust.
>>> 
>>> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
>>> 
>>> This entire procedure may be modified, and there are a few suggestions on the mailing list
>>> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
>>> 
>>> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
>>> 
>>> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
>>> 
>>> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
>> 
>> I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?
>> 
>> Chris
>> 
>>> 
>>> -Marcus
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/dd507e7a/attachment-0001.htm>

From jonesc at hep.phy.cam.ac.uk  Thu Dec 22 16:37:39 2022
From: jonesc at hep.phy.cam.ac.uk (Chris Jones)
Date: Thu, 22 Dec 2022 16:37:39 +0000
Subject: Location to store Rust binaries
In-Reply-To: <0DD8EC83-63EC-4561-8783-FCC4A1C67924@hep.phy.cam.ac.uk>
References: <0DD8EC83-63EC-4561-8783-FCC4A1C67924@hep.phy.cam.ac.uk>
Message-ID: <9F8362CA-7CB7-44EF-B0CD-7B8B74138FED@hep.phy.cam.ac.uk>



> On 22 Dec 2022, at 4:29 pm, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> ?
> 
> 
>>> On 22 Dec 2022, at 1:28 pm, mcalhoun at macports.org wrote:
>>> 
>> ?
>> Please forgive me if I am misunderstanding your question.
>> As Ken pointed out, the rust-bootstrap binaries are generated just fine.
>> I suppose it might be possible to include https://packages.macports.org/ in the `master_sites` of the Rust port.
>> I am afraid I would have to thing about that a little.
> 
> My question is simply I am not getting what the reason is why you cannot make rust depend on rust-bootstrap when it needs to, on older systems, as a standard port dependency. Does *all* older systems have to use the binaries built on 10.9, or can rust-bootstrap be built fine as a port in 10.8, 10.7 etc. as well ?
> 
> Even if the answer to that last question is yes, only the 10.9 binaries can be used, I still feel like something custom could be done to allow the use of the standard binary tarball port distribution, so yes packages.macports.org, to distribute the 10.9 binaries of rust-bootstrap to all builds that need it. Basically, I see no need to use any other binary distribution infrastructure than the one we are already using for the regular binary tarballs.

Just looking at 

 https://packages.macports.org/rust-bootstrap/

Any idea why the binaries for 10.9 (darwin13) do not seem to be available there ?

Chris
> 
> Cheers Chris
> 
>> 
>> -Marcus
>> 
>>> On Dec 22, 2022, at 2:30 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>> 
>>> 
>>> 
>>>>> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
>>>>> 
>>>> ?
>>>> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
>>>> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
>>>> 
>>>> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
>>>> Currently, these binaries are stored on using my personal GitHub account.
>>>> 
>>>> So the entire upgrade process is essentially:
>>>> 1) Update the version in rust-bootstrap.
>>>> 2) Build Rust binaries on a 10.9 VM.
>>>> 3) Upload Rust binaries to GitHub account.
>>>> 4) On older machines, use MacPorts Rust binaries to build Rust.
>>>>     On newer machines, us the upstream provides binaries to build Rust.
>>>> 
>>>> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
>>>> 
>>>> This entire procedure may be modified, and there are a few suggestions on the mailing list
>>>> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
>>>> 
>>>> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
>>>> 
>>>> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
>>>> 
>>>> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
>>> 
>>> I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?
>>> 
>>> Chris
>>> 
>>>> 
>>>> -Marcus
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/aaa1605b/attachment.htm>

From jonesc at hep.phy.cam.ac.uk  Thu Dec 22 16:42:51 2022
From: jonesc at hep.phy.cam.ac.uk (Chris Jones)
Date: Thu, 22 Dec 2022 16:42:51 +0000
Subject: Location to store Rust binaries
In-Reply-To: <9F8362CA-7CB7-44EF-B0CD-7B8B74138FED@hep.phy.cam.ac.uk>
References: <9F8362CA-7CB7-44EF-B0CD-7B8B74138FED@hep.phy.cam.ac.uk>
Message-ID: <A4CAB3BE-C809-4FB1-B148-123E33E7BE01@hep.phy.cam.ac.uk>



> On 22 Dec 2022, at 4:38 pm, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> ?
> 
> 
>>> On 22 Dec 2022, at 4:29 pm, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>> 
>> ?
>> 
>> 
>>>> On 22 Dec 2022, at 1:28 pm, mcalhoun at macports.org wrote:
>>>> 
>>> ?
>>> Please forgive me if I am misunderstanding your question.
>>> As Ken pointed out, the rust-bootstrap binaries are generated just fine.
>>> I suppose it might be possible to include https://packages.macports.org/ in the `master_sites` of the Rust port.
>>> I am afraid I would have to thing about that a little.
>> 
>> My question is simply I am not getting what the reason is why you cannot make rust depend on rust-bootstrap when it needs to, on older systems, as a standard port dependency. Does *all* older systems have to use the binaries built on 10.9, or can rust-bootstrap be built fine as a port in 10.8, 10.7 etc. as well ?
>> 
>> Even if the answer to that last question is yes, only the 10.9 binaries can be used, I still feel like something custom could be done to allow the use of the standard binary tarball port distribution, so yes packages.macports.org, to distribute the 10.9 binaries of rust-bootstrap to all builds that need it. Basically, I see no need to use any other binary distribution infrastructure than the one we are already using for the regular binary tarballs.
> 
> Just looking at 
> 
>  https://packages.macports.org/rust-bootstrap/
> 
> Any idea why the binaries for 10.9 (darwin13) do not seem to be available there ?

I guess the answer is looking at

 https://ports.macports.org/port/rust-bootstrap/builds/

Is that the builds on the older systems have not run yet.

But, yes, once they have I don?t see way the above is not just used as the means to distribute the binaries for rust-bootstrap, either as a regular port build dependency, or if that cannot work for some reason a more custom fetch and extract of the relevant tarball from the above area.

Chris

> 
> Chris
>> 
>> Cheers Chris
>> 
>>> 
>>> -Marcus
>>> 
>>>> On Dec 22, 2022, at 2:30 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>> 
>>>> 
>>>> 
>>>>>> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
>>>>>> 
>>>>> ?
>>>>> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
>>>>> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
>>>>> 
>>>>> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
>>>>> Currently, these binaries are stored on using my personal GitHub account.
>>>>> 
>>>>> So the entire upgrade process is essentially:
>>>>> 1) Update the version in rust-bootstrap.
>>>>> 2) Build Rust binaries on a 10.9 VM.
>>>>> 3) Upload Rust binaries to GitHub account.
>>>>> 4) On older machines, use MacPorts Rust binaries to build Rust.
>>>>>     On newer machines, us the upstream provides binaries to build Rust.
>>>>> 
>>>>> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
>>>>> 
>>>>> This entire procedure may be modified, and there are a few suggestions on the mailing list
>>>>> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
>>>>> 
>>>>> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
>>>>> 
>>>>> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
>>>>> 
>>>>> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
>>>> 
>>>> I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?
>>>> 
>>>> Chris
>>>> 
>>>>> 
>>>>> -Marcus
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/e5dca654/attachment-0001.htm>

From mcalhoun at macports.org  Thu Dec 22 18:29:54 2022
From: mcalhoun at macports.org (mcalhoun at macports.org)
Date: Thu, 22 Dec 2022 11:29:54 -0700
Subject: Location to store Rust binaries
In-Reply-To: <0DD8EC83-63EC-4561-8783-FCC4A1C67924@hep.phy.cam.ac.uk>
References: <D381A7E2-CB77-4AFD-B92D-3930A9379D12@macports.org>
 <0DD8EC83-63EC-4561-8783-FCC4A1C67924@hep.phy.cam.ac.uk>
Message-ID: <09AABC72-4542-4A3A-B6D6-A21C9F14ADDD@macports.org>

rust-bootstrap can not build on older systems because the upstream binaries won?t run.

One downside to using the buildbots for distfiles is that there would be a time period when the 10.5-10.8 buildbots wold fail to build Rust because the 10.9 buildbot hadn?t finished building rust-bootstrap.

-Marcus

> On Dec 22, 2022, at 9:28 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> 
> 
>> On 22 Dec 2022, at 1:28 pm, mcalhoun at macports.org wrote:
>> 
>> ?
>> Please forgive me if I am misunderstanding your question.
>> As Ken pointed out, the rust-bootstrap binaries are generated just fine.
>> I suppose it might be possible to include https://packages.macports.org/ in the `master_sites` of the Rust port.
>> I am afraid I would have to thing about that a little.
> 
> My question is simply I am not getting what the reason is why you cannot make rust depend on rust-bootstrap when it needs to, on older systems, as a standard port dependency. Does *all* older systems have to use the binaries built on 10.9, or can rust-bootstrap be built fine as a port in 10.8, 10.7 etc. as well ?
> 
> Even if the answer to that last question is yes, only the 10.9 binaries can be used, I still feel like something custom could be done to allow the use of the standard binary tarball port distribution, so yes packages.macports.org, to distribute the 10.9 binaries of rust-bootstrap to all builds that need it. Basically, I see no need to use any other binary distribution infrastructure than the one we are already using for the regular binary tarballs.
> 
> Cheers Chris
> 
>> 
>> -Marcus
>> 
>>> On Dec 22, 2022, at 2:30 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>> 
>>> 
>>> 
>>>> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
>>>> 
>>>> ?
>>>> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
>>>> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
>>>> 
>>>> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
>>>> Currently, these binaries are stored on using my personal GitHub account.
>>>> 
>>>> So the entire upgrade process is essentially:
>>>> 1) Update the version in rust-bootstrap.
>>>> 2) Build Rust binaries on a 10.9 VM.
>>>> 3) Upload Rust binaries to GitHub account.
>>>> 4) On older machines, use MacPorts Rust binaries to build Rust.
>>>>     On newer machines, us the upstream provides binaries to build Rust.
>>>> 
>>>> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
>>>> 
>>>> This entire procedure may be modified, and there are a few suggestions on the mailing list
>>>> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
>>>> 
>>>> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
>>>> 
>>>> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
>>>> 
>>>> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
>>> 
>>> I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?
>>> 
>>> Chris
>>> 
>>>> 
>>>> -Marcus
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/8c9f44b0/attachment.htm>

From jonesc at hep.phy.cam.ac.uk  Thu Dec 22 18:51:34 2022
From: jonesc at hep.phy.cam.ac.uk (Chris Jones)
Date: Thu, 22 Dec 2022 18:51:34 +0000
Subject: Location to store Rust binaries
In-Reply-To: <09AABC72-4542-4A3A-B6D6-A21C9F14ADDD@macports.org>
References: <09AABC72-4542-4A3A-B6D6-A21C9F14ADDD@macports.org>
Message-ID: <8FCF9B25-A0C4-43D0-956B-FB88D53C8768@hep.phy.cam.ac.uk>



> On 22 Dec 2022, at 6:30 pm, mcalhoun at macports.org wrote:
> 
> ?rust-bootstrap can not build on older systems because the upstream binaries won?t run.
> 
> One downside to using the buildbots for distfiles is that there would be a time period when the 10.5-10.8 buildbots wold fail to build Rust because the 10.9 buildbot hadn?t finished building rust-bootstrap.

I don?t see the issue as in practise you would just update rust-bootstrap, wait for the binaries to be ready and then update rust.

The advantage of using the regular macports infrastructure to build and distribute the bootstrap binaries seems to me to well outweigh this small disadvantage.

> 
> -Marcus
> 
>>> On Dec 22, 2022, at 9:28 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>> 
>>> 
>>> 
>>>> On 22 Dec 2022, at 1:28 pm, mcalhoun at macports.org wrote:
>>>> 
>>> ?
>>> Please forgive me if I am misunderstanding your question.
>>> As Ken pointed out, the rust-bootstrap binaries are generated just fine.
>>> I suppose it might be possible to include https://packages.macports.org/ in the `master_sites` of the Rust port.
>>> I am afraid I would have to thing about that a little.
>> 
>> My question is simply I am not getting what the reason is why you cannot make rust depend on rust-bootstrap when it needs to, on older systems, as a standard port dependency. Does *all* older systems have to use the binaries built on 10.9, or can rust-bootstrap be built fine as a port in 10.8, 10.7 etc. as well ?
>> 
>> Even if the answer to that last question is yes, only the 10.9 binaries can be used, I still feel like something custom could be done to allow the use of the standard binary tarball port distribution, so yes packages.macports.org, to distribute the 10.9 binaries of rust-bootstrap to all builds that need it. Basically, I see no need to use any other binary distribution infrastructure than the one we are already using for the regular binary tarballs.
>> 
>> Cheers Chris
>> 
>>> 
>>> -Marcus
>>> 
>>>> On Dec 22, 2022, at 2:30 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>> 
>>>> 
>>>> 
>>>>>> On 22 Dec 2022, at 4:02 am, mcalhoun at macports.org wrote:
>>>>>> 
>>>>> ?
>>>>> As many of you know, the Rust compiler is self-hosting, so Rust is required to build Rust.
>>>>> The problem is that the Rust binaries provided by upstream only work on macOS 10.9 and above.
>>>>> 
>>>>> To get around this, there is a rust-bootstrap port that build Rust binaries on 10.9+ intended to build Rust on previous macOS version.
>>>>> Currently, these binaries are stored on using my personal GitHub account.
>>>>> 
>>>>> So the entire upgrade process is essentially:
>>>>> 1) Update the version in rust-bootstrap.
>>>>> 2) Build Rust binaries on a 10.9 VM.
>>>>> 3) Upload Rust binaries to GitHub account.
>>>>> 4) On older machines, use MacPorts Rust binaries to build Rust.
>>>>>     On newer machines, us the upstream provides binaries to build Rust.
>>>>> 
>>>>> This is far from ideal, but it has allowed us to get Rust working back to 10.5 (both i386 and x86_64).
>>>>> 
>>>>> This entire procedure may be modified, and there are a few suggestions on the mailing list
>>>>> (https://lists.macports.org/pipermail/macports-dev/2022-December/thread.html#44855).
>>>>> 
>>>>> However, until consensus is reached about major changes, it would be nice to make some incremental improvements.
>>>>> 
>>>>> The easiest change: does anyone know of a better place to store the MacPorts generated binaries?
>>>>> 
>>>>> More challenging: can anyone think of a way to automate the process of building the MacPorts Rust binaries after rust-bootstrap is update?
>>>> 
>>>> I am sure I am missing something but if the bootstrap binaries are generated via a port, rust-bootstrap, why cannot the usual mechanism for distributing the port as a binary not be used ?
>>>> 
>>>> Chris
>>>> 
>>>>> 
>>>>> -Marcus
>>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221222/3dc1db07/attachment-0001.htm>

From ken.cunningham.webuse at gmail.com  Fri Dec 23 02:39:53 2022
From: ken.cunningham.webuse at gmail.com (Ken Cunningham)
Date: Thu, 22 Dec 2022 18:39:53 -0800
Subject: Location to store Rust binaries
Message-ID: <C1A5697B-4112-4B00-84D1-878C44F77DFE@gmail.com>

Here is a commit where I installed a binary from the packages server onto a different system than it belonged to.

Something similar might work to install the 10.9 binary of rust-bootstrap on 10.5 through 10.8?

https://github.com/macports/macports-ports/commit/39f5b1344934fd8777143d548c2fb04ef4affec6



Ken


From fw at fwright.net  Thu Dec 29 04:59:23 2022
From: fw at fwright.net (Fred Wright)
Date: Wed, 28 Dec 2022 20:59:23 -0800 (PST)
Subject: Maintainer Abuse
Message-ID: <6c63a54-c521-a460-69cd-28a7e6c2327@fwright.net>


Twice recently I've had changes made to ports I maintain without 
respecting the maintainer timeout (and not for any urgent security-related 
reasons).  The first was py-serial, where the change was merged without 
waiting for the maintainer timeout.  And just now I see that someone 
abused their write access to bypass the PR mechanism entirely for a gpsd 
update, so that I wasn't even notified of the change.  And I've had good 
reason to hold off on updating gpsd, due to its missing dependency on 
asciidoctor, which is currently broken on some platforms due to the 
insistence on tying it to a broken version of ruby, which I've actually 
been working on fixing.

Is this now the Wild West?

Fred Wright

From jmr at macports.org  Thu Dec 29 05:57:49 2022
From: jmr at macports.org (Joshua Root)
Date: Thu, 29 Dec 2022 16:57:49 +1100
Subject: Maintainer Abuse
In-Reply-To: <6c63a54-c521-a460-69cd-28a7e6c2327@fwright.net>
References: <6c63a54-c521-a460-69cd-28a7e6c2327@fwright.net>
Message-ID: <6eb81846-08fa-d862-7651-55a718d16df8@macports.org>

On 2022-12-29 15:59 , Fred Wright wrote:
> 
> Twice recently I've had changes made to ports I maintain without 
> respecting the maintainer timeout (and not for any urgent 
> security-related reasons).? The first was py-serial, where the change 
> was merged without waiting for the maintainer timeout.? And just now I 
> see that someone abused their write access to bypass the PR mechanism 
> entirely for a gpsd update, so that I wasn't even notified of the 
> change.? And I've had good reason to hold off on updating gpsd, due to 
> its missing dependency on asciidoctor, which is currently broken on some 
> platforms due to the insistence on tying it to a broken version of ruby, 
> which I've actually been working on fixing.
> 
> Is this now the Wild West?
> 
> Fred Wright

Hi Fred,

Sorry you've been put out by these commits. Both of these ports are 
marked as openmaintainer, which according to the project policy [1] 
means that minor changes are allowed without obtaining the maintainer's 
permission first. That certainly isn't carte blanche to do whatever you 
want, but it does mean that pushing changes directly isn't necessarily 
against the rules.

The definition of a minor update is left somewhat vague, but can 
probably be thought of as synonymous with low-risk. I would say anything 
beyond simple bugfixes, and certainly anything that changes the API or 
ABI, should be run by the maintainer first. And as the policy says, the 
committer is responsible for ensuring that the changes work properly. If 
you push a change to someone else's port, you should consider yourself 
"on the hook" for fixing anything that breaks as a result.

When in doubt, run it by the maintainer.

I'm not familiar enough with gpsd to say whether the recent update was 
minor or not. Marius, please work with Fred to resolve any issues that 
it may have caused.

If the change to py-serial you're referring to was mine of Dec 13, that 
was part of a mass update to adopt a new feature in MacPorts 2.8.0, 
which only touched openmaintainer and nomaintainer ports. IMO it was 
well within the definition of a minor change.

If you would like your permission to be required for all changes to 
these ports, the openmaintainer tag can be removed from the maintainers 
option.

HTH,
- Josh

[1] <https://guide.macports.org/chunked/project.update-policies.html>

From fw at fwright.net  Fri Dec 30 05:05:48 2022
From: fw at fwright.net (Fred Wright)
Date: Thu, 29 Dec 2022 21:05:48 -0800 (PST)
Subject: Maintainer Abuse
In-Reply-To: <FC450F16-1E2D-49FF-B93E-10253EE03B29@gmail.com>
References: <6c63a54-c521-a460-69cd-28a7e6c2327@fwright.net>
 <FC450F16-1E2D-49FF-B93E-10253EE03B29@gmail.com>
Message-ID: <ac186b83-1470-788-e0da-7af1bb60a55a@fwright.net>


On Thu, 29 Dec 2022, Joshua Root wrote:
> On 2022-12-29 15:59 , Fred Wright wrote:
>> 
>> Twice recently I've had changes made to ports I maintain without respecting 
>> the maintainer timeout (and not for any urgent security-related reasons). 
>> The first was py-serial, where the change was merged without waiting for 
>> the maintainer timeout.? And just now I see that someone abused their write 
>> access to bypass the PR mechanism entirely for a gpsd update, so that I 
>> wasn't even notified of the change.? And I've had good reason to hold off 
>> on updating gpsd, due to its missing dependency on asciidoctor, which is 
>> currently broken on some platforms due to the insistence on tying it to a 
>> broken version of ruby, which I've actually been working on fixing.
>> 
>> Is this now the Wild West?

> Sorry you've been put out by these commits. Both of these ports are marked as 
> openmaintainer, which according to the project policy [1] means that minor 
> changes are allowed without obtaining the maintainer's permission first. That 
> certainly isn't carte blanche to do whatever you want, but it does mean that 
> pushing changes directly isn't necessarily against the rules.

My understanding is that only time-critical changes, or stuff in the 
"cleanup" category, should be pushed without maintainer input.

> The definition of a minor update is left somewhat vague, but can probably be 
> thought of as synonymous with low-risk. I would say anything beyond simple 
> bugfixes, and certainly anything that changes the API or ABI, should be run 
> by the maintainer first. And as the policy says, the committer is responsible 
> for ensuring that the changes work properly. If you push a change to someone 
> else's port, you should consider yourself "on the hook" for fixing anything 
> that breaks as a result.

More on "minor" and "low risk" below.

> When in doubt, run it by the maintainer.
>
> I'm not familiar enough with gpsd to say whether the recent update was minor 
> or not. Marius, please work with Fred to resolve any issues that it may have 
> caused.
>
> If the change to py-serial you're referring to was mine of Dec 13, that was 
> part of a mass update to adopt a new feature in MacPorts 2.8.0, which only 
> touched openmaintainer and nomaintainer ports. IMO it was well within the 
> definition of a minor change.

That isn't the change I was referring to (but see below); I was referring 
to 66c7d25d427.  I had no objection to adding the py310 subport (though 
checking still would have been appropriate), but I strongly object to the 
removal of the py34-py36 subports.  And no change that removes a 
capability can be considered "low risk" by any stretch of the imagination.

I'm a firm believer in maximum compatibility, and one of the things I like 
about MacPorts is its support for a wide range of OS versions (though 
adequate testing is often lacking).  But for some reason, that same 
courtesy isn't extended to older Python versions, and some even think that 
it's a good idea to engage in rampages of ethnic cleansing of older Python 
subports.

One shouldn't look to the python.org folks for guidance on this issue; 
those are the same folks that (initially) expected everyone to immediately 
migrate to Python 3, and explicitly discouraged making code simultaneously 
compatible with both Python 2 and Python 3 at all.  But Python versions 
can't be mixed within a single execution of a single program, so a given 
program and all its imported modules have to be compatible with at least 
one Python version.  Similarly, every module needs to have at least one 
Python version compatible with itself and every program that uses it. 
This creates a massive interconnected web of Python code that needs to be 
simultaneously compatible with at least one Python version.  Denying 
simultaneous Python 2/3 compatibility was tantamount to expecting the 
majority of all Python code in the entire world to be converted in 
lockstep from Python 2 to Python 3, which was utterly insane (particularly 
given that a lot of that code is maintained by volunteers 
working in their spare time).

Once the pitchfork-carrying mobs appeared at the gates, the python.org 
folks relented and provided documentation and recommendations for 
"polyglot" code that works with both Python 2 and Python 3.  They also 
extended the support period for Python 2.7, but even the extended period 
was woefully inadequate.  There are substantial incompatibilities between 
Python 2 and Python 3, and it takes real work to fix existing Python 2 
code to handle Python 3.  I know of at least one project that was still 
fixing bugs related to Python 3 many months after dropping support for 
Python 2, so that running it with Python 2 wasn't an available workaround.

Personally, I now try to write all *new* Python code so that it's 
compatible with both, and I've fixed a substantial amount of my existing 
code to do so, but I still have a substantial amount of code that hasn't 
yet been fixed for Python 3, so my default Python is still 2.7.

On another ML, there was a brief discussion related to Python versions on 
Google App Engine.  Someone who was instrumental in the development of 
both Python itself and Google App Engine posted this:
------------------------------------------------------------------------
In 2020 a Googler told me that 2.7 was going to stay "for the foreseeable
future". When the end really comes, I plan to just move to Azure. :-)
------------------------------------------------------------------------

The "newer may be brokener" principle isn't limited to Python 2 vs. Python 
3.  Thanks to the ill-conceived PEP 475, any program expecting a simple, 
straightforward interaction between signals and select() or poll() is 
broken in Python >=3.5.  Even though the rationale for PEP 475 is 
inapplicable to select/poll, its approach was inflicted on them anyway. 
In Python >=3.5, in order for a signal to unblock a select/poll, it needs 
to use either one approach that's somewhat more complicated and also has a 
bug requiring a kludgy workaround that may not be 100% reliable, or 
another approach that's more complicated and poorly documented.  Hence, 
certain programs that don't want to contend with that mess shouldn't use 
anything later than Python 3.4, and Python 3.4 joins Python 2.7 in the 
list of versions that need to be kept around for the forseeable future to 
avoid forcing breakage on users' code.

There may be other such cases; these are just the ones I'm aware of, and 
the python.org folks have a very cavalier attitude toward breaking things. 
The only way to avoid both foreseen and unforeseen problems is to avoid 
removing versions altogether.  Version removal is like a war game - the 
only way to win is not to play.

Some folks like to obsess over avoiding anything that doesn't get 
"security updates".  But this concern is largely overblown, especially in 
the EOL case.  A security fix is only relevant if it applies to a feature 
that a given user or piece of software is actually using.  And for a 
"mature" version (which probably applies to anything EOLed), it's quite 
likely that all the bugs in the widely used features have already been 
discovered, and the remaining ones are in relatively obscure features that 
are far less likely to be used in any given case.

That being said, if anyone wants to avoid EOLed software *themselves*, 
they're perfectly welcome to do so, but they shouldn't be forcing their 
judgment of what's appropriate on everyone else.

Regarding maintainability, a port with significant patches becomes *more* 
maintainable when it's EOLed, since it's no longer necessary to reconcile 
local patches with upstream changes.

Regarding 46ab9a2e798 - it would be best to defer adding 'any' to 
'platforms' anywhere until "port lint" is fixed to stop treating that as 
an error.

> If you would like your permission to be required for all changes to these 
> ports, the openmaintainer tag can be removed from the maintainers option.

That would be a possibility, though I didn't think it was supposed to be 
necessary.

On Thu, 29 Dec 2022, Marius Schamschula wrote:

> As I?m the one to blame for the update to gpsd, let me explain:
>
> 1) gpsd is a dependency of Stellarium which needs a major update. Two 
> maintainers were working on this last night and found that the default 
> dependency tree asked for Python 2.7 and py27-serial (more on that 
> later)

Other variants have been available for quite some time (thanks to Michael
Dickens).

> 2) MacPorts currently supports py37, py38, py39 and py310. As of Sunday, 
> that?ll be py38, py39, 310 and py311. There?s a reason for that: 
> upstream support. Python 2.7 should not be used, never mind, the default 
> anymore.

I completely disagree - see above regarding Python versions.

Although "port upgrade" tries to avoid breaking existing installs by 
preferring current installed variants to new (possibly changed) default 
variants, that only works when the old variants are actually available. 
Removing a variant altogether when it was formerly the default is 
extremely rude.  There needs to be a substantial minimum time (probably 
measured in months) between when a default variant is made not the default 
and when the old default variant is removed (if ever).  And a suitable 
deprecation warning is warranted as well.

> As far as py-serial: the name is confusing.  For a personal project 
> (weewx) I had created a local version (pyserial is the upstream name) as 
> PyPi has a ?serial? package that does serialization rather than serial 
> port support. I only figured out this redundancy when trying to install 
> gpsd.

I agree that the naming is confusing.  I didn't create the port - I just 
took it over from nomaintainer.  Perhaps someone thought that py-pyserial 
smacked too much of the Department of Redundancy Department.  But changing 
it now probably isn't worth the potential additional confusion.

BTW (as documented in the Portfile comments), gpsd's dependency on 
py-serial is "soft", in the sense that it's mostly fine without it, with 
just a couple of its programs having reduced capability in that case. 
But since py-serial is so lightweight, it didn't seem worth making it a 
variant.

Fred Wright

From jmr at macports.org  Fri Dec 30 05:33:40 2022
From: jmr at macports.org (Joshua Root)
Date: Fri, 30 Dec 2022 16:33:40 +1100
Subject: Maintainer Abuse
In-Reply-To: <ac186b83-1470-788-e0da-7af1bb60a55a@fwright.net>
References: <6c63a54-c521-a460-69cd-28a7e6c2327@fwright.net>
 <FC450F16-1E2D-49FF-B93E-10253EE03B29@gmail.com>
 <ac186b83-1470-788-e0da-7af1bb60a55a@fwright.net>
Message-ID: <0c76d8b9-5443-5900-189e-418261aa3ab0@macports.org>

On 2022-12-30 16:05 , Fred Wright wrote:
> 
> On Thu, 29 Dec 2022, Joshua Root wrote:
>> If the change to py-serial you're referring to was mine of Dec 13, 
>> that was part of a mass update to adopt a new feature in MacPorts 
>> 2.8.0, which only touched openmaintainer and nomaintainer ports. IMO 
>> it was well within the definition of a minor change.
> 
> That isn't the change I was referring to (but see below); I was 
> referring to 66c7d25d427.? I had no objection to adding the py310 
> subport (though checking still would have been appropriate), but I 
> strongly object to the removal of the py34-py36 subports.? And no change 
> that removes a capability can be considered "low risk" by any stretch of 
> the imagination.

OK. I agree that deleting a port requires its maintainer's approval.

- Josh

From steve.t.smith at gmail.com  Sat Dec 31 11:46:37 2022
From: steve.t.smith at gmail.com (Steven Smith)
Date: Sat, 31 Dec 2022 06:46:37 -0500
Subject: Ventura Upgrade Requires Reinstall of Commandlinetools to Build
 Haskell cabal-Based Tools
Message-ID: <711046C3-1A0C-4845-A25B-30B3C7B7A3BD@gmail.com>

FYSA,

An upgraded Ventura system on either Apple silicon or Intel is observed not have the directory

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

required for prebuilt Haskell cabal tools, and most likely other projects.

This can be fixed by uninstalling and reinstalling Command Line Tools.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4420 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221231/d9003d17/attachment.bin>