Last Comment Bug 1284816 - Require Rust to build
: Require Rust to build
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: Unspecified Unspecified
-- normal with 3 votes (vote)
: mozilla54
Assigned To: Ralph Giles (:rillian) | needinfo me
:
: Gregory Szorc [:gps] (away until 2017-03-20)
Mentors:
Depends on: 1283898
Blocks: 1104619 encoding_rs 1287162 Quantum 1336153
  Show dependency treegraph
 
Reported: 2016-07-06 03:40 PDT by Ted Mielczarek [:ted.mielczarek]
Modified: 2017-02-07 03:24 PST (History)
37 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
fixed

MozReview Requests
Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:
Show discarded requests

Attachments
Bug 1284816 - Remove --disable-rust. (59 bytes, text/x-review-board-request)
2017-02-01 15:41 PST, Ralph Giles (:rillian) | needinfo me
ted: review+
Details | Review

Description User image Ted Mielczarek [:ted.mielczarek] 2016-07-06 03:40:48 PDT
At some point we're going to require Rust to build Firefox. This is a blocker to writing any critical components in Rust. Once we've fixed the blockers of bug 1283898 this is primarily just a political decision. It will mean that non-Tier-1 platforms may have a harder time building Firefox, but I think we're OK with that.
Comment 1 User image Sylvestre Ledru [:sylvestre] 2016-08-01 02:53:26 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #0)
> It will
> mean that non-Tier-1 platforms may have a harder time building Firefox, but
> I think we're OK with that.
To give more explanations with my Debian packager hat, Rust becoming a mandatory requirement means:
* Rust has to be supported on the OS or arch
* As Rust is based on LLVM, LLVM has to be properly supported on the OS and arch
* As a nice side effect, as most of the GNU/Linux distro are still using gcc to build LLVM (and clang) and LLVM is not too afraid to require new C++ features, that means that, in some cases, gcc has to be backported (this is the case for some old Ubuntu LTS being still supported)
* Rust moves super fast and has a tight dependency on the latest LLVM stable version. If Firefox code uses the most recent features of Rust, that means that backporting Firefox involves backporting Rust + LLVM (and potentially gcc).

I am not saying we should not do it, just explaining the impact on non-tier-1 platforms
Comment 2 User image Petr Cerny [:hrosik] 2016-08-12 05:05:33 PDT
(In reply to Sylvestre Ledru [:sylvestre] from comment #1)
> * Rust moves super fast and has a tight dependency on the latest LLVM stable
> version. If Firefox code uses the most recent features of Rust, that means
> that backporting Firefox involves backporting Rust + LLVM (and potentially
> gcc).
> 
> I am not saying we should not do it, just explaining the impact on
> non-tier-1 platforms

As a side note, LTS distributions of any kind (RH/SLE/Ubuntu LTS) would be helped tremendously if Firefox ESR required no rustc upgrades during its lifetime (i.e. fixes in the Rust code not needing newer Rust features then on the day of fork from the rapid release).
Comment 3 User image Ted Mielczarek [:ted.mielczarek] 2016-08-12 08:25:32 PDT
> (In reply to Ted Mielczarek [:ted.mielczarek] from comment #0)
> I am not saying we should not do it, just explaining the impact on
> non-tier-1 platforms

I agree that this could be a significant burden. However, we've decided that the advantage of using Rust is too great here. If the outcome is that Firefox doesn't ship on non-Tier-1 platforms we are OK with that. We normally don't go out of our way to make life harder for people maintaining Firefox ports, but in this case we can't let lesser-used platforms restrict us from using Rust in Firefox.

I suspect that for the Debian case where it's just Linux on other CPU architectures, once someone does the work to port LLVM to that architecture and gets that upstreamed then the future maintenance burden should not be great. (This does assume that Rust converges on using upstream LLVM.)

(In reply to Petr Cerny [:hrosik] from comment #2)
> As a side note, LTS distributions of any kind (RH/SLE/Ubuntu LTS) would be
> helped tremendously if Firefox ESR required no rustc upgrades during its
> lifetime (i.e. fixes in the Rust code not needing newer Rust features then
> on the day of fork from the rapid release).

That is totally reasonable and we should codify that. I don't know if we have it written down anywhere, but we've generally avoided taking toolchain updates on stable branches.(In reply to Sylvestre Ledru [:sylvestre] from comment #1)
Comment 4 User image Henri Sivonen (:hsivonen) 2016-08-13 01:04:37 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3)
> I suspect that for the Debian case where it's just Linux on other CPU
> architectures, once someone does the work to port LLVM to that architecture
> and gets that upstreamed then the future maintenance burden should not be
> great. (This does assume that Rust converges on using upstream LLVM.)

https://www.debian.org/distrib/netinst indicates that Debian runs on   

 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mipsel
 * powerpc
 * ppc64el
 * s390x

The Rust team already ships rustc and cargo for amd64 aka. x86_64 and for the ARM variants:
https://github.com/rust-lang-nursery/rustup.rs/#other-installation-methods

Additionally, the Rust team ships rustc and cargo for i686. From forum posts I understand that it's possible to target x86 without SSE2 at least.

Additionally, https://forge.rust-lang.org/platform-support.html indicates that cross-compiling the standard library for mips and mipsel is already part of the Rust team's continuous integration, so one might assume mips and mipsel to work with reasonable effort.

powerpc is listed as tier 3, but it's unclear if someone is actively keeping it working.

That leaves only the IBM server architectures, ppc64el and s390x, as unsupported. Debian already has LLVM for those: https://packages.debian.org/search?keywords=llvm&searchon=names&suite=stable&section=all . It's unclear to me how relevant ppc64el and s390x are to desktop applications.

So:

 * amd64: Shipped by the Rust team both via the traditional installer and rustup.rs
 * arm64: Shipped by the Rust team both via rustup.rs
 * armel: Shipped by the Rust team both via rustup.rs
 * armhf: Shipped by the Rust team both via rustup.rs
 * i386: Needs a special target config (i686 shipped by the Rust team)
 * mips: Tier 2 for Rust
 * mipsel: Tier 2 for Rust
 * powerpc: Tier 3 for Rust
 * ppc64el: LLVM exists
 * s390x: LLVM exists
Comment 5 User image Lars Bergstrom (:larsberg) 2016-08-15 08:31:38 PDT
In conversations with Linux distro maintainers, it has come up that it would be nice if we could avoid *requiring* Rust until after the next ESR, Firefox 52. So far as I can tell, this would only mean that we should not add features that are Rust-only until 52 leaves m-c, which from https://wiki.mozilla.org/RapidRelease/Calendar seems to indicate early/mid-September.

Since most of the work we are doing right now has a C++ fallback (or is running both the Rust and C++ side-by-side for testing reasons), that seems like a reasonable request.
Comment 6 User image Brian Anderson 2016-08-15 16:31:55 PDT
Fedora also wants s390, ppc64 and ppc64le, and Martin Stransky described the need as 'critical'. But it's not clear to me still whether the lack of support for any particular architecture is a showstopper for either Debian or Fedora, whether they can just drop Firefox from those architectures. It's also not clear to me that they need a compiler *hosted* for those platform - in theory they could cross-compile, but I imagine for simplicity all architectures are purely self-hosting, that is, they use build servers that correspond to that architecture. I'll try to clarify.

Also note that Rust's in-tree ARM definitions are a mess: https://github.com/rust-lang/rust/issues/35590. I wouldn't necessarily expect that to prevent packagers from creating their own target definitions that worked to their liking, but we're trying to get it all sorted out. Debian says this is blocking armhf support for them.

There's some indication that Rust will produce powerpc64le compilers in the (relatively) near future, but there is no movement on the others. It is quite difficult to maintain builds for all these platforms, but if we need to produce compilers for all these second-tier architectures then it's mostly just a matter of work.

It's also worth noting that Rust's support for most of these second-tier architecture amounts to just producing builds - except for arm/android we do not verify that they actually produce working code, and they often do not. Getting all these architectures under _test_ will truly be difficult. Just building them is mostly a matter of cross-compiling and uploading to S3. Testing requires hardware, emulators, etc.
Comment 7 User image Mike Hommey [:glandium] 2016-08-15 17:11:30 PDT
(In reply to Brian Anderson from comment #6)
> Fedora also wants s390, ppc64 and ppc64le, and Martin Stransky described the
> need as 'critical'. But it's not clear to me still whether the lack of
> support for any particular architecture is a showstopper for either Debian
> or Fedora, whether they can just drop Firefox from those architectures. It's
> also not clear to me that they need a compiler *hosted* for those platform -
> in theory they could cross-compile, but I imagine for simplicity all
> architectures are purely self-hosting, that is, they use build servers that
> correspond to that architecture. I'll try to clarify.

For Debian that's the case. No cross-compilation is done for any package (which is actually quite painful in some cases, like Firefox, where building (which, incidentally, includes running some tests) on the slowest build slaves on the slowest architectures, can take more than 24 hours)

> It's also worth noting that Rust's support for most of these second-tier
> architecture amounts to just producing builds - except for arm/android we do
> not verify that they actually produce working code, and they often do not.
> Getting all these architectures under _test_ will truly be difficult. Just
> building them is mostly a matter of cross-compiling and uploading to S3.
> Testing requires hardware, emulators, etc.

I'm not at all convinced you need to do that on your end. If a second-tier port is essentially about triples and LLVM support, there are small chances they will break with Rust changes, right? So as long as people interested in second-tier ports build and test them, and you accept patches when something broke, I don't see why you'd need to provide (untested) cross-compiled versions of rustc for those platforms. Especially now that you can build rustc $version+1 with rustc $version.
Comment 8 User image Martin Stránský 2016-08-15 23:53:02 PDT
(In reply to Brian Anderson from comment #6)
> Fedora also wants s390, ppc64 and ppc64le, and Martin Stransky described the
> need as 'critical'. 

Sorry, I was misleading here. Critical for Red Hat is that next ESR cycle (Firefox 52) will not require Rust so we have time to prepare build environment.
Comment 9 User image Martin Stránský 2016-08-16 00:10:24 PDT
(In reply to Brian Anderson from comment #6)
> Fedora also wants s390, ppc64 and ppc64le, and Martin Stransky described the
> need as 'critical'. But it's not clear to me still whether the lack of
> support for any particular architecture is a showstopper for either Debian
> or Fedora, whether they can just drop Firefox from those architectures. It's
> also not clear to me that they need a compiler *hosted* for those platform -
> in theory they could cross-compile, but I imagine for simplicity all
> architectures are purely self-hosting, that is, they use build servers that
> correspond to that architecture. I'll try to clarify.

Fedora does not cross-compile any package and we use hosted compilers with all the issues Mike mentioned. And yes, Fedora can drop Firefox on specific arches and ship Firefox only on the working ones.
Comment 10 User image Jan Beich 2016-11-28 07:49:12 PST
Landry & Martin, are OpenBSD and NetBSD prepared to build Firefox with --enable-rust at least on x86 architectures?

https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg20261.html
Comment 11 User image Landry Breuil (:gaston) 2016-11-28 08:01:04 PST
(In reply to Jan Beich from comment #10)
> Landry & Martin, are OpenBSD and NetBSD prepared to build Firefox with
> --enable-rust at least on x86 architectures?
> 
> https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg20261.html

Lol, as if we had any choice. amd64 will, i386 doesnt have a working rust yet.
Comment 12 User image Martin Husemann 2016-11-28 10:17:23 PST
(In reply to Landry Breuil (:gaston) from comment #11)
> (In reply to Jan Beich from comment #10)
> > Landry & Martin, are OpenBSD and NetBSD prepared to build Firefox with
> > --enable-rust at least on x86 architectures?
> > 
> > https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg20261.html
> 
> Lol, as if we had any choice. amd64 will, i386 doesnt have a working rust
> yet.

No, we are not ready for that.
Firefox "portability" has become a bad joke, last working version on big endian machines for me is 44.
I am about to completely punt on the project and search for alternatives.
Comment 13 User image Landry Breuil (:gaston) 2016-11-28 10:19:53 PST
I'm using netsurf on powerpc, and midori on i386/low-end atom...
Comment 14 User image Cameron Kaiser [:spectre] 2016-11-28 11:35:49 PST
(In reply to Martin Husemann from comment #12)
> Firefox "portability" has become a bad joke, last working version on big
> endian machines for me is 44.

I got TenFourFox 45 off the ground with a couple endian hacks, but we don't use Skia at all in Tiger, which is where I suspect other major endian problems lurk (though not relevant to this bug specifically). Contact me if you want them -- they're in our changesets too.
Comment 15 User image Martin Husemann 2016-12-06 00:55:40 PST
(In reply to Martin Husemann from comment #12)
> Firefox "portability" has become a bad joke, last working version on big
> endian machines for me is 44.

I take that back and would like to honestly apologize.
Writing this comment with Firefox 50.0.2 on sparc64...

Another NetBSD developer is working on making rust more portable to other NetBSD platforms, including i386 and sparc64 (which is quite painful work).

So: we are not ready, but we are getting closer.

Still I think requiring an essentially non- (or at least hard-) portable language like Rust is not a good idea for a portable project, but only time will tell if this was a good decision or not.
Comment 16 User image Ralph Giles (:rillian) | needinfo me 2017-02-01 15:35:34 PST
As an update, I'm intending to resolve this bug soon.

If you're maintaining Firefox on a platform without good rust support you'll be able to continue for a bit, but starting with Firefox 55 I expect not having rust to require disabling features affecting user security. For Firefox 53 (release 2017 April 18) you can build with `--disable-rust`. For Firefox 54 you'll probably be able to revert changes from this bug and still get a working build. We're not testing non-rust configurations and intend to land code which makes it non-optional, so keeping a --disable-rust variant working will be increasingly difficult after that.
Comment 17 User image Ralph Giles (:rillian) | needinfo me 2017-02-01 15:38:22 PST
(In reply to Martin Husemann from comment #15)

> [...] only time will tell if this was a good decision or not.

Very true, and sorry for adding to the port burden. We believe it will be worthwhile. Thanks for your hard work keeping Firefox running!
Comment 18 User image Ralph Giles (:rillian) | needinfo me 2017-02-01 15:41:17 PST Comment hidden (mozreview-request)
Comment 19 User image Ralph Giles (:rillian) | needinfo me 2017-02-01 15:54:14 PST Comment hidden (mozreview-request)
Comment 20 User image Ted Mielczarek [:ted.mielczarek] 2017-02-01 18:02:12 PST
Comment on attachment 8832681 [details]
Bug 1284816 - Remove --disable-rust.

https://reviewboard.mozilla.org/r/108876/#review110126

::: build/moz.configure/rust.configure:7
(Diff revision 2)
>  # vim: set filetype=python:
>  # This Source Code Form is subject to the terms of the Mozilla Public
>  # License, v. 2.0. If a copy of the MPL was not distributed with this
>  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
>  
> -option('--disable-rust', help='Don\'t include Rust language sources')
> +rustc = check_prog('RUSTC', ['rustc'], allow_missing=True)

Might want a comment indicating that `rust_compiler` below makes this required. Alternately, you could just remove `allow_missing`, but we would have a less-good error message.
Comment 21 User image Ted Mielczarek [:ted.mielczarek] 2017-02-02 06:23:45 PST
As a followup we should remove the `MOZ_RUST` subst and define.
Comment 22 User image Ralph Giles (:rillian) | needinfo me 2017-02-02 10:06:44 PST Comment hidden (mozreview-request)
Comment 23 User image Ralph Giles (:rillian) | needinfo me 2017-02-02 10:07:39 PST
Comment added per review. Carrying r=ted.
Comment 24 User image Pulsebot 2017-02-02 10:08:42 PST
Pushed by rgiles@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/eb1677e32680
Remove --disable-rust. r=ted
Comment 25 User image Wes Kocher (:KWierso) 2017-02-02 15:58:43 PST
https://hg.mozilla.org/mozilla-central/rev/eb1677e32680
Comment 26 User image John Paul Adrian Glaubitz 2017-02-03 07:48:17 PST
Just as a heads-up: On Debian, rustc currently builds on i386 (which is actually i686), amd64 (x86_64) and arm64 [1]. According to Debian's Rust maintainers, maintaining Rust on non-x86 besides arm64 seems to be very troublesome and involved [2].

So, with the current situation, making rustc a requirement for Firefox will effectively kill Firefox on everything but i386, amd64 and arm64 for Debian unless someone is really willing to pick up all the extra burden to fix rustc on the non-x86 platforms.

I honestly think that killing the portability of Firefox is a bad decision and might lead to Debian or other projects forking Firefox again like it happened with Iceweasel to allow keep using the browser on targets like the Raspberry Pi or modern embedded MIPS machines.

> [1] https://buildd.debian.org/status/package.php?p=rustc&suite=sid
Comment 27 User image Botond Ballo [:botond] 2017-02-03 08:13:24 PST
(In reply to John Paul Adrian Glaubitz from comment #26)
> According to Debian's Rust
> maintainers, maintaining Rust on non-x86 besides arm64 seems to be very
> troublesome and involved [2].

^ Missing link
Comment 28 User image Manish Goregaokar [:manishearth] 2017-02-03 08:16:56 PST
I think the Rust team was planning on upping the breadth of the official builds, and this was gated on the CI system being overhauled (in progress, should be done soon). So that should not be the issue by then.


Note that you don't need to fork firefox; you can disable the rust dependency without a fork. Until Firefox 53 (last release of 2017), disabling Rust will not cause any loss of functionality. As :rillian mentioned this start causing features to go missing from Firefox 54, in which case a fork doesn't help unless you are going to implement the features yourself (at which point just fixing the rustc problems, if not already fixed by the Rust team, would be easier?).
Comment 29 User image Manish Goregaokar [:manishearth] 2017-02-03 08:17:41 PST
(In reply to Botond Ballo [:botond] from comment #27)

> ^ Missing link


I suspect it's http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20161226/000758.html


We had breakages on ARM recently.
Comment 30 User image John Paul Adrian Glaubitz 2017-02-03 08:22:10 PST
(In reply to Manish Goregaokar [:manishearth] from comment #29)
> (In reply to Botond Ballo [:botond] from comment #27)
> 
> > ^ Missing link
> I suspect it's
> http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-
> 20161226/000758.html

Yes, this one. Sorry and thanks for helping me out :).
Comment 31 User image John Paul Adrian Glaubitz 2017-02-03 08:31:21 PST
(In reply to Manish Goregaokar [:manishearth] from comment #28)
> I think the Rust team was planning on upping the breadth of the official
> builds, and this was gated on the CI system being overhauled (in progress,
> should be done soon). So that should not be the issue by then.

"Should" is a conjunctive which is the main problem I am seeing. It's been promised for a while but still hasn't happened.

> Note that you don't need to fork firefox; you can disable the rust
> dependency without a fork. Until Firefox 53 (last release of 2017),
> disabling Rust will not cause any loss of functionality.

Yes, I'm aware of that. But with this bug report being resolved, the direction has already been set.

> As :rillian mentioned this start causing features to go missing from Firefox 54,
> in which case a fork doesn't help unless you are going to implement the features yourself

Well, the fork would, of course, be based on a version prior the huge change 54 will bring.

> (at which point just fixing the rustc problems, if not already fixed by the Rust team, would be easier?).

I'm not sure if all that is going to happen soon. According to Sylvestre's message [1], LLVM - which is used by Rust - doesn't even run the testsuite on most architectures, so I'm not sure how much sense it makes to work with a compiler which doesn't pass its own testsuite.

I'm just skeptical that rustc will reach Tier1 status on non-x86 targets in the foreseeable future which is why I'm worried by this decision. 32-bit ARM is one of the biggest Linux markets and not having Firefox available there would be at least weird.

> [1] http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20161226/000759.html
Comment 32 User image Manish Goregaokar [:manishearth] 2017-02-03 08:43:48 PST
> It's been promised for a while but still hasn't happened.

Most of the work is done now. It's been going on for most of this month and the last. Moving release packaging to the new system is a bit more involved, but AIUI the work is going on.

This effort is a large one, I wouldn't expect it to happen immediately.


> Well, the fork would, of course, be based on a version prior the huge change 54 will bring.

There is literally no point in doing that. --disable-rust on 54 only means that you won't get some speed improvements. --disable-rust on 55 means that you may not get newer features from 55 (because they will be written in pure Rust), which is what happens when you fork anyway, except if you fork you may also lose out on other patches. Unless you're willing to rewrite these features in C++ in the fork, the fork will always be worse off than --disable-rust.


I'm not sure what the plan for the far future is with respect to dropping support completely for non-Rust builds (at which point I expect a stronger guarantee from Rust), but for now just disabling Rust is unambiguously a better solution than forking.

--------------


Could you list all of the platforms that you need?
Comment 33 User image Botond Ballo [:botond] 2017-02-03 09:17:02 PST
(In reply to Manish Goregaokar [:manishearth] from comment #32)
> --disable-rust on 54 only means
> that you won't get some speed improvements. --disable-rust on 55 means that
> you may not get newer features from 55 (because they will be written in pure
> Rust)

I'm a bit confused. Isn't the patch that landed in this bug removing --disable-rust from 54 trunk, so that there's no such thing as "--disable-rust on 54" and "--disable-rust on 55"?
Comment 34 User image Cameron Kaiser [:spectre] 2017-02-03 09:18:08 PST
(In reply to John Paul Adrian Glaubitz from comment #31)
> Well, the fork would, of course, be based on a version prior the huge change
> 54 will bring.

You would be better served IMHO using 52ESR as your base, which doesn't require Rust either, and gets security patches. That gives you until Fx59 to get it right, if getting rustc up on your architectures is the desired goal. That's what I would have done with TenFourFox, except lots of breaking changes occurred between 45 and 52 that would require unmaintainable amounts of churn to revert, so we're forking after 45 (I'm a solitary port maintainer nowadays, and I don't have enough stamina to maintain a browser *and* LLVM *and* rustc on OS X Tiger PowerPC).
Comment 35 User image Manish Goregaokar [:manishearth] 2017-02-03 09:33:53 PST
(In reply to Botond Ballo [:botond] from comment #33)
> (In reply to Manish Goregaokar [:manishearth] from comment #32)
> > --disable-rust on 54 only means
> > that you won't get some speed improvements. --disable-rust on 55 means that
> > you may not get newer features from 55 (because they will be written in pure
> > Rust)
> 
> I'm a bit confused. Isn't the patch that landed in this bug removing
> --disable-rust from 54 trunk, so that there's no such thing as
> "--disable-rust on 54" and "--disable-rust on 55"?

It is, and I misunderstood the situation (there's a different bug which added disable-rust) my apologies.


Yep, ESR makes sense here.


Does the rust package actually need the LLVM package to exist? AIUI rust uses a pinned LLVM version. I don't think it can be built with an LLVM release yet (this used to be sort of possible, but stopped being the case at some point). At least, that's how I understand the situation, this could have changed again. Is it acceptable to build the LLVM compiler  pinned as a submodule? If rust does run the testsuite for $target (doesn't right now, but should in the future), would that be sufficient, or is it the case that rust must use an LLVM release for packaging?
Comment 36 User image Josh Stone 2017-02-03 09:49:47 PST
(In reply to Manish Goregaokar [:manishearth] from comment #35)
> Does the rust package actually need the LLVM package to exist? AIUI rust
> uses a pinned LLVM version. I don't think it can be built with an LLVM
> release yet (this used to be sort of possible, but stopped being the case at
> some point).

Rust does still support external LLVM 3.7+, and I'm pretty sure bors even has a 3.7 test to make sure this keeps working.  We build it this way on Fedora, currently using our packaged llvm-3.8 on F24/F25 and llvm-3.9 on rawhide.  Using a bundled LLVM would be permitted by our packaging policy, but not preferred.
Comment 37 User image Manish Goregaokar [:manishearth] 2017-02-03 09:51:21 PST
That's great to hear!
Comment 38 User image Brian Anderson 2017-02-03 10:27:08 PST
Some clarifications about Rust platform support and CI.

The coverage improvements Rust has promised to this point to support Firefox on Linux are implemented: mips, ppc, and s90x builds of rustc [1] [2]. If there is more needed or expected from the Rust team at this time, I am not aware, and would like to discuss it (ideally not on this bug).

[1]: https://github.com/rust-lang/rust/issues/36006
[2]: https://github.com/rust-lang/rust/issues/36015

Today we don't test Rust on non-x86 Linux targets, but there is a PR open to add an ARM target tested via qemu [3].

[3]: https://github.com/rust-lang/rust/pull/39400

There are no plans presently to increase coverage beyond that.
Comment 39 User image Ted Mielczarek [:ted.mielczarek] 2017-02-03 10:54:17 PST
I believe we've said this before, but while it's unfortunate that requiring Rust may mean that building Firefox on non-x86/arm CPU architectures may be hard or impossible we are investing heavily into Rust and we believe that the benefits to Firefox are worthwhile. The Rust team seems generally interested in broadening the number of platforms supported by the Rust toolchain, so I think the situation will improve over time. Regardless, we're sympathetic but we are still going to proceed with this plan.
Comment 40 User image John Paul Adrian Glaubitz 2017-02-03 11:03:47 PST
(In reply to Brian Anderson from comment #38)
> The coverage improvements Rust has promised to this point to support Firefox
> on Linux are implemented: mips, ppc, and s90x builds of rustc [1] [2]. If
> there is more needed or expected from the Rust team at this time, I am not
> aware, and would like to discuss it (ideally not on this bug).

Implementation isn't enough though. The ports for these targets have to be actively maintained and tested, otherwise they aren't really something you want to rely on for production code. I have seen too many compiler bugs in gcc and others on more exotic targets for exactly this reason.

> Today we don't test Rust on non-x86 Linux targets, but there is a PR open to
> add an ARM target tested via qemu [3].

Running a compiler testsuite on QEMU is courageous, to say the least. In Debian, we don't allow builds for release architectures on emulated hardware for very good reasons. There have been multiple cases in the past where compilers generated wrong code when executed on QEMU. I have made plenty of experiences in this regard.

Really, you *need* a complete CI setup with real hardware for all the ports you actually want to support like Google does for golang [1]. Otherwise claiming to support any of such architectures is a bit dishonest.

What are all these fancy new memory safety and code quality of Rust worth if you can't actually guarantee that the compilers generates correct code? I have the impression that the Rust team takes this responsibility a bit too light-heartedly.

> [1] https://build.golang.org/
Comment 41 User image Nathan Froyd [:froydnj] 2017-02-03 11:09:11 PST
Like Brian already said, discussion of the suitableness of Rust's support for these architectures and/or their CI system should be taken someplace else.
Comment 42 User image Martin Husemann 2017-02-06 00:56:11 PST
Will any version of rustc be ok or will the dependencies be "recentish rustc" (for whatever value of recentish)? Asked the other way around: if we manage to have rustc setup on a build system once, will we be required to track rust developement?
Comment 43 User image Landry Breuil (:gaston) 2017-02-06 01:01:17 PST
(In reply to Martin Husemann from comment #42)
> Will any version of rustc be ok or will the dependencies be "recentish
> rustc" (for whatever value of recentish)? Asked the other way around: if we
> manage to have rustc setup on a build system once, will we be required to
> track rust developement?

I think you already know the sad answer to this :) I just hope the 'you need the very latest release of $whatever' trend doesnt reach release/beta channels....
Comment 44 User image Ted Mielczarek [:ted.mielczarek] 2017-02-06 03:28:33 PST
I suspect there will be a little while here where we wind up requiring the latest stable version. Rust 1.15 added support for custom derive macros, which are needed for quite a few useful things (like auto-generated serialization code with serde). Rust is still a young language, and Servo/Gecko development is driving some feature work. I don't expect that this will be a long-term trend, however.
Comment 45 User image John Paul Adrian Glaubitz 2017-02-06 03:30:52 PST
(In reply to Landry Breuil (:gaston) from comment #43)
> (In reply to Martin Husemann from comment #42)
> > Will any version of rustc be ok or will the dependencies be "recentish
> > rustc" (for whatever value of recentish)? Asked the other way around: if we
> > manage to have rustc setup on a build system once, will we be required to
> > track rust developement?
> 
> I think you already know the sad answer to this :) I just hope the 'you need
> the very latest release of $whatever' trend doesnt reach release/beta
> channels....

Is this some sort of joke? Do you really expect distributions to constantly update to the latest git snapshot of the Rust compiler just because they are updating their Firefox package?

I'm sorry, but this isn't maintainable in the long run. Because if we have to update the Rust compiler to be able to build the new Firefox version, we will most likely unrelated Rust packages and that is not acceptable.

Stable ABIs and APIs exist for very practical reasons.
Comment 46 User image Sylvestre Ledru [:sylvestre] 2017-02-06 04:37:43 PST
John, we are aware of all that. However, in order to move fast, we made the call to follow rust's versions.
We are aware that this is going to be a pain for Linux distro (especially Debian with the long cycles) but as Ted said, this won't be a long term requirement.
Until then, in Debian, ESR52 doesn't require Rust to compile. Debian stable will have some time to figure out a solution
Comment 47 User image Manish Goregaokar [:manishearth] 2017-02-06 08:34:26 PST
> Do you really expect distributions to constantly
> update to the latest git snapshot of the Rust compiler just because they are
> updating their Firefox package?


The latest stable distribution, not the latest git snapshot. Rust has a stable release every six weeks.

Rust does have a stable API. The point is that Firefox will wish to use newer APIs, at least for the near future (As ted says in the long-term this shouldn't be the case).
Comment 48 User image John Paul Adrian Glaubitz 2017-02-07 03:10:09 PST
(In reply to Sylvestre Ledru [:sylvestre] from comment #46)
> John, we are aware of all that. However, in order to move fast, we made the
> call to follow rust's versions.

This is going to create lots of issues for the distributions.

> We are aware that this is going to be a pain for Linux distro (especially
> Debian with the long cycles) but as Ted said, this won't be a long term
> requirement.

I'm not sure why you can't make Rust stable first, then go ahead and move into production. You are basically using the distributions and their users as test guinea-pigs which isn't acceptable.

> Until then, in Debian, ESR52 doesn't require Rust to compile. Debian stable
> will have some time to figure out a solution

There isn't really any other way to resolve this than providing a stable API and language. Google is doing that with golang, why can't Mozilla do it for Rust?
Comment 49 User image John Paul Adrian Glaubitz 2017-02-07 03:11:03 PST
(In reply to Manish Goregaokar [:manishearth] from comment #47)
> Rust does have a stable API. The point is that Firefox will wish to use
> newer APIs, at least for the near future (As ted says in the long-term this
> shouldn't be the case).

Then most distributions will not be able to ship the latest version of Firefox for the time being.
Comment 50 User image Sylvestre Ledru [:sylvestre] 2017-02-07 03:24:42 PST
I don't think this is the place to continue the discussion. Please move the discussion to dev-platform or to rust packaging list.
Please see those threads with Rust upstream, Rust downstream and Firefox people:
http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20160829/000548.html
http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20160822/000541.html
http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20160822/000534.html

Note You need to log in before you can comment on or make changes to this bug.