(rust) Cargo dependencies



  • I know 'dogfooding' is usually a good idea, but I really don't get the reasoning behind this gem:

    In order to build Cargo (Rust's packaging and build system), you need (among other dependencies) a working Cargo binary on your platform.

    The build script solves this by downloading a "minimal" precompiled binary snapshot for your platform.

    Couple of things come to mind:

    1. Downloading random binary blob and running it on my system? (Possibly with root permissions, when you're trying to install Cargo.)
    2. What if my platform isn't "supported" and there isn't a binary snapshot available? Should I just hand-compile and hand-assemble and hand-link Cargo, so that I can later build Cargo with it?

    I get the impression that this is one of those "because we can" things. Doing stuff just for the sake of stuff.



  • Isn't this the same issue C compilers have?


  • Discourse touched me in a no-no place



  • @Jaime said:

    Isn't this the same issue C compilers have?

    I agree that it's similar. But C is a compiler (and often one of the first things to get ported to an entirely new platform), while Cargo is a package manager / build system. It needs a separate Rust compiler.

    I wanted to write "It would be similar if make required 'make' to be present on the system to build itself", but I went to check and GNU Make actually does that 😮

    Seems it's not that unusual after all ...



  • Well, what alternative would you suggest? I'm not familiar with Cargo, but if it's the build system, I imagine it includes the compiler and other tools?

    Usually, bootstrapping a new system where you'll use C means writing a basic C compiler in assembly, which you then feed a real C compiler written in C, which you then use to build the optimized version of itself. Analogously (huh, that's a word), you would have to write Cargo in assembly, then feed your assembly-Cargo a Rust-Cargo source, and then rebuild Cargo in optimized mode with itself. At which point you'd have the same binary that you can just download from the project page.



  • It's a tough problem, I agree.

    Personally, I'd provide a simplified, minimal build script using sh, to get the minimal binary, which would then build the real thing. Though that raises further questions about which "*sh" exactly.

    Just to clarify a bit: Cargo is written in Rust, and Rust compiler is written in C++.
    So there should be no problem to port both Rust and Cargo to a system, which has a (competent) C++ compiler, plus Python and GNU make and some other tidbits.

    The only snag is that Cargo uses Cargo as its build system (in lieu of something like make).

    I do agree that it's a very good test of the system (dogfooding), but it does make it harder to support new platforms.


  • ♿ (Parody)

    @Kian said:

    Usually, bootstrapping a new system where you'll use C means writing a basic C compiler in assembly, which you then feed a real C compiler written in C, which you then use to build the optimized version of itself.

    Isn't a more modern thing to make a cross compiler first? And then you have a blob that can be used on the target system.

    @ashkante said:

    I do agree that it's a very good test of the system (dogfooding), but it does make it harder to support new platforms.

    Do they not support cross compiling?



  • @boomzilla said:

    Do they not support cross compiling?

    You raise a valid point. I'll give it a try one of these days if I get some free time.
    Though that means I have to set up a Linux box just for this purpose and try to cross-compile minimal Cargo to FreeBSD.

    Still seems like a hassle when I already have a fully functional Rust compiler on FreeBSD.


  • ♿ (Parody)

    Or...

    That comment says the following builds cargo without cargo:

    NB: The most I've done with anything rust is reading about it around here.



  • Thanks - I was already there before. The linked patch seemed to be for a version of Cargo, which is too old to help with bootstrapping a more recent git clone.

    It's just that the whole "using our tool to build our tool" made me go "WTF!?". (hence the original post)


Log in to reply