Re: sh4 architecture into Wheezy
On 04/26/2011 08:36 PM, Aurelien Jarno wrote:
On Tue, Apr 26, 2011 at 04:41:23PM +0200, Matthias Klose wrote:
On 04/26/2011 09:39 AM, Neil McGovern wrote:
I woudn't be particularly happy with that unless the gcc maintainers ok
it, and I'm still not sure that two days is also an acceptable
then please drop mips and mipsel as release architectures. At least
What is your problem about MIPS? Why do you insist about dropping it? At
least be fair and don't spread FUD.
GCC on mips/mipsel build in less than 2 days on the recent build
machines. It's true that the build time is slightly higher than other
architectures, but the testsuite is done on 3 different ABIs. This is
something that can be tweaked, as suggested for SH4.
Here are the average build time for gcc-4.* since the release of
| mips | mipsel |
gcc-4.3 | 42864 | 141863 |
gcc-4.4 | 104400 | 149148 |
gcc-4.5 | 123498 | 114435 |
gcc-4.6 | 95725 | 167799 |
gcc-4.6: 167799/3600 = 46.61, and this is with the libstdc++ testsuite already
disabled, because it did timeout or fail on the mipsel buildds. So this is *no*
FUD. Did you look at the build failures, or some other mips porter, before I
did disable the tests?
The build time dispersion is explained by the fact we have buildds of
different speed, gcc-* is built by default on them (no_weak_autobuild),
unless this build daemon is already busy.
sh4 has a workable, accessible developer machine,
mips also has an accessible developer machine, gabrielli.debian.org.
It's true that mipsel doesn't have one (it's being working on), that
said, most issues are reproducible on both. People can also ask on
debian-mips for help in case it's a mipsel specific issue.
and people within
Debian who care about the architecture.
MIPS also has Debian people who care about the architecture. See for
example my recent MIPS work:
yes, the last one incomplete and only completed by myself. So who else is doing
toolchain work on mips in Debian? Thiemo did leave a big gap, and it was an
effort of many people to release squeeze with mips. I just see that
All that said, I agree that mips and mipsel architectures are not in
their best shape, but people are working on that. If you consider they
don't follow the release criteria, please give objective arguments.
the build time argument was brought up by the debian-release team, so this this
seems to be an objective argument. If not, maybe the release criteria for new,
current and "obsolet" ports should be made more transparent. I'm only aware of
one table not differentiating new and current ports.
yes, other issues are the non-availabilty of a mipsel porter box and the
instability of the existing mips porter box.
and toolchain maintenance was rather difficult (longsoon, binutils) during the
Please note that this thread did start about sh4, and some comments about the
sh4 toolchain by some members of the release team, which apply for mips* too,
and which are used against the sh4 port.
I appreciate your work on mips, but I think a lot more needs to be done to keep
it as a release architecture, and that arguments that are overlooked by intent
for existing release architectures should not be used against a new port.