Location to store Rust binaries

[Chris Jones]

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