4 ms·

Because a lot of companies, at least those that develop their own internal software (on Linux for example) often stick to the compiler the system ships with, e.

• Manishearth 10y ago
  In rusts case it sounds like we will ship rustup.rs in distros, since it is also intended to be how people obtain cross compilers and whatnot. I could be wrong about this -- I am aware of, but not directly involved in, the plans for rustup. If not via rustup, I would expect everything that can be fetched via rustup to be in the package repo. This solves the problem for clippy but not for afl, though there are solutions there too. The GCC plugin for afl requires you to find the right GCC sources and compile against those (unless you use the hacky, less-awesome assembly based afl). This solution is available to you for afl-rs too, just not documented because using a nightly is easier. This makes afl-rs just as bad as GCC in this aspect. afl-rs needs a nightly not because it only works on specific versions, but because it hooks into the compiler in a way that is only allowed on nightly. Thus it will work on any nightly, even that from a few weeks ago, but it must be a nightly. As I mentioned it is possible to get it to work if you are willing to do what GCC does.
  • kbenson 10y ago
    > In rusts case it sounds like we will ship rustup.rs in distros I sincerely doubt any enterprise level distribution will make that the primary source of obtaining a rust compiler. I would bet good money that Red Hat won't. It's counter to most of the reason enterprise distributions exist in the first place, which is a stable (often at the cost of many other feature) base on which to build and support. If they aren't doing this, they aren't an enterprise distribution. This goes as far as Red Hat back-porting bug-fixes to 7 year old versions of utilities and libraries, because any change .needs to be backwards compatible at all cost. Additionally, there's the question of ensuring that all relevant portions of the rust install are removed on package removal. At the same time, getting the source and every patch applied to it, and the complete compile instruction for a package is generally very easy. It's meant to be repeatable. For Red Hat, you just get the appropriate srpm instead of rpm, and that unpacks a source tarball and any associated patches separated, along with an rpmbuild config that contains all the info used to build an rpm package from them. Every single thing, including the kernel is built this way. That's not to say rustup won't possibly be shipped as an extra utility, in one of th emain rust packages or as a separate one, but it definitely won't be the primary method most distributions provide for rust development (in the case of the non-enterprise distros, because it's just not as convenient as saying "install rust" and having it just be there, in a confirmed tested version that works with whatever other packaged tooling they provide. There are downsides to this, but there are also many benefits.
    • Manishearth 10y ago
      Right, which is why I said for such distros I expect rustup-obtainable extras to be packaged as well and installed in the same way. Again, unsure if this is the actual plan.
      • kbenson 10y ago
        I'm not sure where you said that, so I'm not sure what context to interpret that in. Does "rustup-obtainable extras to be packaged as well and installed in the same way" mean packaged through distro specific packaging mechanism, or something else? My only point in this part of the thread, which has little to do with the "we use gcc because it's stable" argument, is just that you shouldn't expect the distros the change how they ship just for rust, which expecting them to use rustup would be (in what I think are the majority of cases). If rust as a community expects rustup to be what distros use, then I think there's a disconnect from reality happening, and it's worth looking at because if that's important to rust (which I don't know, honestly), then it should be addressed. I understand that you may not know if this is the actual plan. Note: I don't particularly think rust requirly a nightly build for this is important. Organizations will look at it and assess it as a tool as needed, and if they think it's worth using and they want to roll it out, they'll package it in some manner if that's important to them (and that might just be a tarball, at the simpler level), or they won't if it's not. Stability is important, but at the tooling level, it's much less so, and being able to make sure all yours devs are in lockstep is probably more important (for large orgs).
        • Manishearth 10y ago
          > "rustup-obtainable extras to be packaged as well and installed in the same way" mean packaged through distro specific packaging mechanism, or something else? yep. I was referring to "If not via rustup, I would expect everything that can be fetched via rustup to be in the package repo." What I meant was: instead of users installing rustup and then installing all the toolchains through rustup (`rustup install stable`, `rustup install arm-linux-gnueabi`, `rustup install clippy`), they can also install `rustc`, `rustc-arm-linux-androideabi` (cross toolchain), `rust-clippy` through the package manager (apt-get install or whatever). Cross compile toolchains for C are often similarly packaged (gcc-cross, etc). The way I understand it (again, unofficial, not sure if it's the actual plan :) ), we would like most users to use rustup as the single source of truth for Rust. This won't work for some setups, including distro packaging, and I'm not sure what the plan is there, but I'd expect it to be something similar to what I wrote above. The binaries that rustup downloads will always be available, regardless, if you are okay with downloading a signed binary once and internally distributing it. But I don't expect it will come to that. Though right now Rust hasn't yet gotten all the ducks in a row for proper distro packaging, so that's all you can use. This is being actively worked on, and IIRC all the major work is done (?)