ing points.
I have already verified that these changes don't break on 32-bit PowerPC,
64-bit SPARC
and, of course, M68k.
Thanks,
Adrian
> [1] https://github.com/python/cpython/pull/24624
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.o
that I could find. And the bug was fixed by Andreas Schwab [2],
so another downstream maintainer which was my point earlier in the discussion.
We downstreams care about the platform support, hence we keep it working.
Thanks,
Adrian
> [1]
> https://github.com/python/cpython/blob/63298930f
> The main thing from a project maintenance perspective is for platforms to
not become a burden to other code maintainers. PRs need to be reviewed.
Every #if/#endif in code is a cognitive burden. So being a minor platform
can come with unexpected breakages that need fixing due to other changes
ma
There are zero technical reasons for what you are planning here.
You are inflating a few lines of autoconf into a "platform support", so you
have a reason to justify adding multiple lines of extra autoconf codes to make
life for downstream distributions harder.
I could understand the maintenanc
Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms.
There is no separate configure guard. All platforms that Rust can build for,
are always enabled by default. No one in Rust keeps anyone from cross-compiling
code for sparc64 or powerpcspe, for example.
So if you want
(Since my first reply here somehow got lost, I'm posting this again).
Rust doesn't prevent anyone from building Tier 2 or Tier 3 targets. There is no
limitation for "legacy" or "deprecated" targets. Any target can be built and
any target can be selected by the Rust compiler for cross-compliation
