Location to store Rust binaries

[Chris Jones]

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