-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Shipping Rust (part 1) #52
base: master
Are you sure you want to change the base?
Conversation
Loosely ported over from Medium format
|
||
So this is two binaries we need to ship, as well as one JSON file. | ||
|
||
First is libstd. We actually want to compile the Rust standard libraries against our target.json, but here we have a problem: how do you do this? … … We use [rust-cross-libs.sh](https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2Ftessel%2Ft2-rustlib%2Fblob%2Fmaster%2Frust-cross-libs.sh), a script to (with some effort) cross-compile the libstd and generate a new libstd according to the target.json file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The makefile-based build system that rust-cross-libs.sh uses is about to be removed. I doubt that script works unmodified to build Rust 1.14 anyway, though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad I waited three months to publish this post! Time to fix the broken http://github.com/tessel/t2-rustlib build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad to see this written. I may not be the target audience, but I'm not sure after reading what was important for me to learn here. Is this instructions for getting started on Rust, more of an explanation of why our Rust support works the way it does, or something else?
***Tessel is an open-source hardware platform for developing IoT devices.*** | ||
|
||
The Tessel board runs an embedded Linux distribution (OpenWRT) and uses a less-common chip architecture: MIPS with soft-float. | ||
Our CLI is designed to require as few steps as possible between plugging in the Tessel board and running code. The board was designed to run Node.js, a runtime for JavaScript, which is an interpreted language. Beyond pruning the amount of code the user has downloaded to that which is actually needed on the device, essentially we just need to tarball a user’s code, unpack it, and run it behind the scenes over an SSH-like pipe: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this meant to have a paragraph break?
|
||
***Tessel is an open-source hardware platform for developing IoT devices.*** | ||
|
||
The Tessel board runs an embedded Linux distribution (OpenWRT) and uses a less-common chip architecture: MIPS with soft-float. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who is the intended audience for this post? This is a tough intro for a general audience, but doesn't mention Rust right away so might not reach that reader either
|
||
***Tessel is an open-source hardware platform for developing IoT devices.*** | ||
|
||
The Tessel board runs an embedded Linux distribution (OpenWRT) and uses a less-common chip architecture: MIPS with soft-float. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spell out soft-float
Blinking! | ||
``` | ||
|
||
When we wanted to expand the CLI tool’s support for the Rust programming language, we had to rethink interactions with the command line tool—instead of running a script directory, you specify the target binary by name, for example—but none were more involved than cross-compilation. Tessel’s architecture is not one compiled by default for Rust, so we have to ship the pieces we need ourselves. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"the CLI tool" --> "Tessel 2's CLI tool"
Blinking! | ||
``` | ||
|
||
When we wanted to expand the CLI tool’s support for the Rust programming language, we had to rethink interactions with the command line tool—instead of running a script directory, you specify the target binary by name, for example—but none were more involved than cross-compilation. Tessel’s architecture is not one compiled by default for Rust, so we have to ship the pieces we need ourselves. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"command line tool–instead" --> "command line tool– instead"
Blinking! | ||
``` | ||
|
||
When we wanted to expand the CLI tool’s support for the Rust programming language, we had to rethink interactions with the command line tool—instead of running a script directory, you specify the target binary by name, for example—but none were more involved than cross-compilation. Tessel’s architecture is not one compiled by default for Rust, so we have to ship the pieces we need ourselves. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following this first sentence. Can you structure it differently?
|
||
Next, we need cross-compiler build tools. OpenWRT, the Linux distribution, is fully described by its binaries and package list. When you compile OpenWRT, you actually compile a series of host tools, then the cross-compiler toolchain, then the Linux kernel, and lastly all the packages going into your distribution. This “compile the world” approach is nice for embedded targets, but we only need the cross-compiler toolchain and any system libraries we want to link against. Luckily, OpenWRT also builds an SDK bundle that we can redistribute with just these. | ||
|
||
The OpenWRT SDK bundle changes with each version of our firmware; since the bundle is big (~200mb) and firmware moves slowly, we made the decision to keep only the latest version of the SDK at all times on the user’s computer. One more caveat: host machine binaries are OS-specific. This means that we can compile an OpenWRT SDK on Linux, and redistribute to Linux systems. With some effort, we can compile an SDK on macOS as well; but compiling on Windows is much trickier, since it requires a Linux environment such as Cygwin or Windows 10 Professional’s Linux subsystem. For the moment, we limit our support to Linux and macOS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"only the latest version of the SDK on the user's computer at all times", right?
|
||
Next, we need cross-compiler build tools. OpenWRT, the Linux distribution, is fully described by its binaries and package list. When you compile OpenWRT, you actually compile a series of host tools, then the cross-compiler toolchain, then the Linux kernel, and lastly all the packages going into your distribution. This “compile the world” approach is nice for embedded targets, but we only need the cross-compiler toolchain and any system libraries we want to link against. Luckily, OpenWRT also builds an SDK bundle that we can redistribute with just these. | ||
|
||
The OpenWRT SDK bundle changes with each version of our firmware; since the bundle is big (~200mb) and firmware moves slowly, we made the decision to keep only the latest version of the SDK at all times on the user’s computer. One more caveat: host machine binaries are OS-specific. This means that we can compile an OpenWRT SDK on Linux, and redistribute to Linux systems. With some effort, we can compile an SDK on macOS as well; but compiling on Windows is much trickier, since it requires a Linux environment such as Cygwin or Windows 10 Professional’s Linux subsystem. For the moment, we limit our support to Linux and macOS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not obvious to me from this paragraph why Windows is harder than macOS. Not sure if that means more explanation is needed.
|
||
The OpenWRT SDK bundle changes with each version of our firmware; since the bundle is big (~200mb) and firmware moves slowly, we made the decision to keep only the latest version of the SDK at all times on the user’s computer. One more caveat: host machine binaries are OS-specific. This means that we can compile an OpenWRT SDK on Linux, and redistribute to Linux systems. With some effort, we can compile an SDK on macOS as well; but compiling on Windows is much trickier, since it requires a Linux environment such as Cygwin or Windows 10 Professional’s Linux subsystem. For the moment, we limit our support to Linux and macOS. | ||
|
||
When running cargo tessel sdk install: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, where are we in this process? Can you better tie this to the above paragraphs?
INFO SDK installed. | ||
``` | ||
|
||
Great! We now have a MIPS libstd and a linker on our machine. But how to use them? It turns out, you can do this with an entirely unmodified cargo binary, all from the command line. We require these environment variables: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as in, now go set these variables?
Loosely ported over from Medium format