Skip to content
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

Package the compiler and expose on a public internet interface #162

Open
dylanmckay opened this issue Mar 31, 2020 · 7 comments
Open

Package the compiler and expose on a public internet interface #162

dylanmckay opened this issue Mar 31, 2020 · 7 comments

Comments

@dylanmckay
Copy link
Member

dylanmckay commented Mar 31, 2020

Started from a message from @Rahix on Gitter https://gitter.im/avr-rust/Lobby?at=5e73360f0f0687340b3ff930

Need to figure out:

  • Which platforms should we package for
  • Which tool to use (custom, something from the embedded-wg, etc)
  • How often prebuilt binaries should be updated
  • Do we require AVR-libc/avr-ld on the host, or do we package that too (could we even due to licensing?

Considerations:

  • Only commits that pass tests should have pre-built binaries automatically packages
@dylanmckay
Copy link
Member Author

@Rahix which OS's/versions do you/the people you know use the compiler on?

@Rahix
Copy link

Rahix commented Mar 31, 2020

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.

@Rahix
Copy link

Rahix commented Mar 31, 2020

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.

@shepmaster
Copy link
Member

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.

@Rahix
Copy link

Rahix commented Apr 3, 2020

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.

@shepmaster
Copy link
Member

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.

@jonahbron
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants