(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 :open_mouth:

    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.



  • @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.



  • 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
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.