Open dylanmckay opened 4 years ago
@Rahix which OS's/versions do you/the people you know use the compiler on?
I'm personally on Archlinux and have seen people using Ubuntu, Debian, and MacOS (ping @peacememories). Distributing my locally built toolchain was often a headache because when I build on my Arch-machine, it links against a very recent glibc which other distros don't ship yet.
Re packaging: From other platforms/languages I am used to shipping a statically linked sys-root containing everything necessary for building. This toolchain is also usually configured against any accidental host contamination (e.g. including from /usr/include
).
I'd like something similar here: I think we should ship a complete sys-root including avr-rust
, avr-llvm-tools
, avr-gcc
, avr-binutils
, and xargo
/cargo-xbuild
.
Licensing is my big worry about such an endeavor.
I agree that we should talk to the embedded WG about this — they may have already stocked it or want to solve something similar.
If we were to do it in a vacuum, I’d suggest distributing an entire Docker image via Docker hub. That way it’s theoretically available to be used on every platform. It’s also more consistent once you get into the container.
Do we require AVR-libc/avr-ld on the host
One reason I’ve always investigated my path is to reduce the number of dependencies. AFAIK I only need avr-ld and something to flash with.
This is also a reason to look into getting llvm linker support for avr.
which OS
I’m on macOS myself.
I’d suggest distributing an entire Docker image via Docker hub.
While I have nothing against doing this additionally, I'd not like this to be the only binary distribution. There are lot's of circumstances where using docker is impossible or comes at a high cost. I'd much prefer a sys-root distribution as described above. Although, if you want a docker distribution as well, I wouldn't see an issue with that.
could we even due to licensing?
I am not a lawyer but from my experience, this should not be an issue. We'd be building all components from source anyway (and using publicly visible infrastructure). Containing GPL components (gcc, binutils) alongside non-GPL components (rustc) is fine as long as they are orthogonal and we can hand out the sources of the GPL components.
There are lot's of circumstances where using docker is impossible or comes at a high cost
Every time I’ve ever listened to anyone talk about packaging anything for a distro, it’s had a fair amount of complaints about the pain of supporting all the various types of input sources and the different types of packaging or supporting X different versions of a distro, etc.
My point for using Docker is to ease the maintainer burden. However, I’m not going to be implementing this either way, so if some other maintainer wishes to shoulder whatever burdens, that’s cool for them.
I spent most of the day trying to figure out how to build and distribute Rust as a container in a way that could be linked to rustup, but couldn't come up with anything good. The best case non-hackish scenario that I could come up with results in all of the compiled output being owned by a different user. It seems like being able to run the compiler binary on the host OS is really what we need. @shepmaster lmk if you have any ideas on this.
Instead I opted for an alternate approach. Short of distributing a compiled Rust compiler, I've at least created a container that can reliably compile the fork for you. No more dependency management, source cloning, nothing. Just one command:
mkdir -p build && docker run --mount "type=bind,src=$PWD/build,dst=/rust/build" jonahbron/avr-rust-builder
You can see the image on Docker Hub, and my blog post about it.
Note that I build a separate container underneath this one, rust-builder. This one is slightly less convenient, but doesn't make any assumptions about what version of Rust you're wanting to build.
Started from a message from @Rahix on Gitter https://gitter.im/avr-rust/Lobby?at=5e73360f0f0687340b3ff930
Need to figure out:
Considerations: