What rust claims about FreeBSD support (as an example involved in picking languages)

[Mark Millard]

[Please view this as just illustrating a technical
issue involved, not as some sort of objection on my
part to various ideas that have been expressed.]


Using rust as an example to illustrate a more general
issue that might be involved in picking languages . . .

https://doc.rust-lang.org/nightly/rustc/platform-support.html reports
its support tier structure relative to FreeBSD as:
(for 32-bit I'll only list armv7 information)


Tier 2 with Host Tools:

x86_64-unknown-freebsd 64-bit FreeBSD


Tier 3 with std and host checkmarked (✓):

aarch64-unknown-freebsd ARM64 FreeBSD
armv7-unknown-freebsd Armv7-A FreeBSD
powerpc64-unknown-freebsd PPC64 FreeBSD (ELFv1 and ELFv2)


Tier 3 with no checkmarks (nor * nor ? for std):

powerpc64le-unknown-freebsd PPC64LE FreeBSD
riscv64gc-unknown-freebsd RISC-V FreeBSD


Tier 2 with Host tools is described via:

QUOTE
Tier 2 targets can be thought of as "guaranteed to build". The Rust project builds official binary releases of the standard library (or, in some cases, only the core library) for each tier 2 target, and automated builds ensure that each tier 2 target can be used as build target after each change. Automated tests are not always run so it's not guaranteed to produce a working build, but tier 2 targets often work to quite a good degree and patches are always welcome!

Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.

Tier 2 targets with host tools additionally support running tools like rustc and cargo natively on the target, and automated builds ensure that the host tools build as well. This allows the target to be used as a development platform, not just a compilation target. For the full requirements, see Tier 2 with Host Tools in the Target Tier Policy.

All tier 2 targets with host tools support the full standard library.
NOTE: The rust-docs component is not usually built for tier 2 targets, so Rustup may install the documentation for a similar tier 1 target instead.
END QUOTE


Tier 3 is described via:

QUOTE
Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work. Official builds are not available. For the full requirements, see Tier 3 target policy in the Target Tier Policy.

The std column in the table below has the following meanings:
• ✓ indicates the full standard library is available.
• * indicates the target only supports no_std development.
• ? indicates the standard library support is unknown or a work-in-progress.

Tier 3 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.

The host column indicates whether the codebase includes support for building host tools.
END QUOTE


I've not looked up the status of any other languages
but I think the above may illustrate the considerations
involved sufficiently.

Some languages may be fairly easy to self support. Others
might require upstream to have some sufficient degree of
support before it would be viable overall/long-term for
FreeBSD to depend on it across a range of platforms,
especially FreeBSD Tier 1 platforms.

An issue for my example (rust) is that as long as FreeBSD
has aarch64 as Tier 1 in FreeBSD terms, might it be that
the rust Tier 3 status of aarch64-unknown-freebsd could
be a problem? Can FreeBSD cover the gap or lead rust to
change the rust Tier 3 status to, say, rust Tier 2 with
Host Tools for aarch64, matching x86_64-unknown-freebsd ?

===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Millard]

[I had not read the rust Tier information prior to what lead
to the use of the material in the original note. I continued
to read after my note and I ran into Tier 2 and Tier 3
criteria relative to PR communication that I'm adding this
time.]

Post by Mark Millard
[Please view this as just illustrating a technical
issue involved, not as some sort of objection on my
part to various ideas that have been expressed.]
Using rust as an example to illustrate a more general
issue that might be involved in picking languages . . .
https://doc.rust-lang.org/nightly/rustc/platform-support.html reports
(for 32-bit I'll only list armv7 information)
x86_64-unknown-freebsd 64-bit FreeBSD
aarch64-unknown-freebsd ARM64 FreeBSD
armv7-unknown-freebsd Armv7-A FreeBSD
powerpc64-unknown-freebsd PPC64 FreeBSD (ELFv1 and ELFv2)
powerpc64le-unknown-freebsd PPC64LE FreeBSD
riscv64gc-unknown-freebsd RISC-V FreeBSD
QUOTE
Tier 2 targets can be thought of as "guaranteed to build". The Rust project builds official binary releases of the standard library (or, in some cases, only the core library) for each tier 2 target, and automated builds ensure that each tier 2 target can be used as build target after each change. Automated tests are not always run so it's not guaranteed to produce a working build, but tier 2 targets often work to quite a good degree and patches are always welcome!
Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.
Tier 2 targets with host tools additionally support running tools like rustc and cargo natively on the target, and automated builds ensure that the host tools build as well. This allows the target to be used as a development platform, not just a compilation target. For the full requirements, see Tier 2 with Host Tools in the Target Tier Policy.
All tier 2 targets with host tools support the full standard library.
NOTE: The rust-docs component is not usually built for tier 2 targets, so Rustup may install the documentation for a similar tier 1 target instead.
END QUOTE
QUOTE
Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work. Official builds are not available. For the full requirements, see Tier 3 target policy in the Target Tier Policy.
• ✓ indicates the full standard library is available.
• * indicates the target only supports no_std development.
• ? indicates the standard library support is unknown or a work-in-progress.
Tier 3 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.
The host column indicates whether the codebase includes support for building host tools.
END QUOTE
I've not looked up the status of any other languages
but I think the above may illustrate the considerations
involved sufficiently.
Some languages may be fairly easy to self support. Others
might require upstream to have some sufficient degree of
support before it would be viable overall/long-term for
FreeBSD to depend on it across a range of platforms,
especially FreeBSD Tier 1 platforms.
An issue for my example (rust) is that as long as FreeBSD
has aarch64 as Tier 1 in FreeBSD terms, might it be that
the rust Tier 3 status of aarch64-unknown-freebsd could
be a problem? Can FreeBSD cover the gap or lead rust to
change the rust Tier 3 status to, say, rust Tier 2 with
Host Tools for aarch64, matching x86_64-unknown-freebsd ?

The following quotes are from:

https://doc.rust-lang.org/rustc/target-tier-policy.html


Tier 3 context's note on PR communication relative to maintaining
the Tier 3 target:

QUOTE
• Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

• Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
END QUOTE

Sounds like aarch64-unknown-freebsd being rust Tier 3 might have
more support issues than I was originally thinking from what I'd
read earlier, given the constraints on some Tier 3 communication.


Tier 2 (with or without Host Tools) context's note on PR
communication relative to ensuring that tests pass for
the Tier 2 target:

QUOTE
• Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.

• Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
END QUOTE

Sounds like x86_64-unknown-freebsd being rust Tier 2 with Host
Tools might have more support issues than I was originally
thinking from what I'd read earlier, given the constraints on
some Tier 2 communication relative to passing tests.



===
Mark Millard
marklmi at yahoo.com



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Chisnall]

Post by Mark Millard
An issue for my example (rust) is that as long as FreeBSD
has aarch64 as Tier 1 in FreeBSD terms, might it be that
the rust Tier 3 status of aarch64-unknown-freebsd could
be a problem? Can FreeBSD cover the gap or lead rust to
change the rust Tier 3 status to, say, rust Tier 2 with
Host Tools for aarch64, matching x86_64-unknown-freebsd ?

I think this is an important problem, but I see it as a bootstrapping problem. There’s no point adding Rust to the base system unless we have people who are good at writing Rust code and who understand the language well who want to contribute. If we have such people, they are in a good position to improve upstream rustc’s FreeBSD support.

The same thing happened with Clang. It was written for OS X and ported to Linux. I fixed a bunch of small bugs early on where FreeBSD’s calling conventions were not quite Linux or not quite OS X, as did a bunch of other people who cared about FreeBSD. This became a much more exciting thing to do once there was a path to Clang replacing GCC in the base system and the Foundation funded some of the work. By the time we flipped the switch, LLVM had a FreeBSD buildbot and we had infrastructure to do ports exp runs with now clang versions.

David

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de