That would be amazing. Even just a rough sketch would help.
I don’t know what timescale you were thinking, but my long-term roadmap for cross-compilation “done right” is:
- stdlib deps RFC
- needs-provides for panic and allocating
cargo build -p stdjust works.
- Cargo always use metadata of hashed content of package with deterministic tarball hash (content-addressed, so works for all dependency types).
- Mozilla signs that metadata of stdlib crates, Cargo tells stable rust to use unstable features on mozilla-signed crates.
- Cargo learns how to use global target dir—deterministic as described above metadata helps avoid collisions, sysroot mock binary source becomes just another cargo target dir as far as Cargo is concerned
- Done! std will be transparently built only the first time compiling for a new target.
Thanks @Ericson2314. That’s a great start! I’ll try to augment that with my thoughts soon.
New someday tasks (updated in the op):
- document rustup source code installation in rustup README
- write up infra thoughts and roadmap for irlo
- cross-platform application demo
- demonstrate cross-platform application with core logic in Rust
- with ui in the native language/api
- unit testing on all platforms
- integrate most comon rust libraries
- cross-platform testing project
- nightly regression testing for all rust targets
- multiple profiles
- std + core platform libraries (log, etc)
- “rust reps”
- each rep gets a kit
- “ask me about rust” t-shirts - reps only
- bag of rust stickers
- rust rep / community-team “business” cards
- 1-sheet talking points and outreach guidance
- follow through on release cycle milestones Release cycle milestones and P-high
cargo testfor cross-targets, maybe
- rustup cross testing https://github.com/rust-lang-nursery/rustup.rs/issues/690
- make forge.rust-lang.org more visible
- move platform support list out of the book into forge, linked from book
- run tests
- test rust code not published to crates.io
- put docs.rs link on www docs page https://docs.rs
- write new single-text file plan to rustup checksum issue
- rename .multirust https://github.com/rust-lang-nursery/rustup.rs/issues/537
What kind of people are you picturing as “Rust reps”, and what needs to be done to organize this? I think I understand Rust philosophically and am eager to use it more, and in fact I’ve nicknamed myself “Rust evangelist” on my company’s internal IM client. However, I haven’t actually done any coding in Rust beyond some tutorials, because we currently use C++ at work, and my family life has been pretty all-consuming outside of work these last few years.
@BatmanAoD Regarding “Rust reps”, the kernel of the idea came from a conversation I had with @Manishearth where he mentioned that he was at a non-Rust related Mozilla event, and people were excited to talk to him about Rust. And I have that experience a fair bit too - I tell people I work on Rust and they’re excited to hear about it. So it seems to me there’s a lot of recognition we could achieve just by having Rust folks seen in various relevant social settings.
So the way I pictured it is that we would have people just get out and attend the normal industry events they usually would (though maybe more-so - I know I don’t get out enough), and be known as “the Rust guy/girl”. In particular, we’re in a phase where we’re in a period where we’re trying to raise the profile of Rust in the Mozilla community, so I figured we would start by just having Rust folks go to Mozilla events (there are a lot of them). That’s really safe: they would be welcome there and not have much risk of coming off as pushy sales people. We could of course also think about expanding to all sorts of events in relevant industries.
The big risk though with such an imitative is representing Rust poorly. It’s easy for evangelism to turn into salesmanship or zealotry, and some already have a negative opinion of the boundless enthusiasm of Rust fans. So we’d want to make sure reps were well prepared with an approach that is consistent with Rust values.
I’ve been working on something like this. Basically, docker + travis + appveyor to test as many (cross) targets as possible. The repository is here. So far I count a test coverage of 21 of 49 targets.
My original goal was to create something where we could test our binary releases of std because, right now, those are untested on most platforms but I guess this could be turned into a general purpose cross testing framework for other Rust projects.
That makes sense.
I do think that the really big problem right now is incorrect assumptions about Rust based on what little people have heard about it. For instance, in a discussion in which I was criticizing C++14’s failure to permit
std::function to contain a
std::unqiue_ptr (or any other non-copyable object), someone was defending C++ by stating that my original design had a “logical” error, and that in fact “given the pedal-to-the-metal nature of C++, this specific issue is unavoidable”. (This idea among the C++ community that all of its flaws are necessary flaws for a “power language” is frighteningly prevalent.) I explained that this issue would be avoidable if
std::function supported move-semantics, and that this gave me the feeling that C++'s move-semantics are a “tacked-on” part of the language rather than a core part of the design as in Rust. The person responded by saying that his “theory” was that Rust handles this situation is “garbage-collected pointers”. I of course explained that Rust does not have garbage collection, but I think the discussion highlights a fairly common misunderstanding–that memory-safe languages necessarily use garbage collection. And in the C++ community, garbage collection seems to be anathema (despite the fact that Bjarne Stroustrup has stated that he has no doubt C++ will some day incorporate garbage collection–a prediction I think is actually pretty unlikely).
@japaric Yay, this is exactly what I was hoping for! Do you know why so many targets are red (and why the badge says the build is passing)? I updated the op to link to your project.
I’ve updated the op with the following new tasks:
- write packaging guidelines https://github.com/rust-lang/rust/issues/29563
- convert niko’s tutorial deck to an HTML format https://github.com/nikomatsakis/rust-tutorials-keynote
- continue producing weekly project changelogs (like https://users.rust-lang.org/t/rust-project-changelog-for-2016-07-15/6555)
- write up ideal rust reporting/accounting/triage procedures
- update and maintain regression sheet https://docs.google.com/spreadsheets/d/1t3Wb77_hNsfnD2ZsCRiBaMYCw3qBQoVhUyP9hPNiczg/edit#gid=0
- weekly compiler-perf report
- commission rust artworks
- investigate opportunities for a lustre-like in Rust
Do you know why so many targets are red?
So right now I’m running all these tests on all the non-windows targets:
- Basic unit testing: #[test], #[should_panic]
- unit tests of each standard crate (e.g. libcollectionstest)
The current HEAD of the repository now runs all these tests even if one of them fails (I basically
make's “keep going” flag) and report at the end which tests failed (if any). That
report looks like this:
FAILURES -------- std.debug std.release libc_test
That’s for the
So far I’m seeing the targets fail for these reasons:
catch_panic: this doesn’t work on the i686-musl target. This is a legit failure and has been reported to the rust-lang/rust issue tracker.
- libc_test: these seem to be due to the glibc/toolchain version I’m using. Note that the test suite doesn’t actually fail, instead it doesn’t even compile (compiling libc-test involves compiling an auto-generated C file, that file doesn’t compile). Most of the targets that appear as failing in my repo pass the test suite on the libc repo, but the libc repo is using older glibcs/toolchains. cf. rust-lang/libc#23 and rust-lang/libc#357
- QEMU is broken for this arch: This is the case for powerpc64le. qemu-ppc64le segfaults when I try to run any binary for this architecture. cf. Debian bug
- libstd’s unit tests segfault: This only happens on cross targets whose unit tests are run under
QEMU. And I think these may be false positive caused by QEMU limitation of handling several threads.
Because I’ve tested a few of these targets locally (also under QEMU) but running only the test
that fails (instead of the whole test suite) and on some runs the test passes and on some runs the
test segfaults. NOTE that in all cases (also in the repository), I always run unit tests with
RUST_TEST_THREADS=1to limit the number of unit tests that runs concurrently to one but a single unit test may still spawn several threads.
- libstd’s unit tests hang: Pretty much the same as above. I think this may be caused by QEMU.
These are the libstd unit tests I’ve seen fail so far:
fs::tests::canonicalize_works_simple net::tcp::tests::connect_loopback net::tcp::tests::multiple_connect_interleaved_greedy_schedule net::tcp::tests::set_nonblocking sync::mpsc::tests::stress_recv_timeout_shared
I’ve yet to dig deeper into these unit tests to figure out which are real failures and which are false positives with 100% certainty though.
The good news is that all the other standard crates (libcoretest, librand, etc) pass their test suites with 100% success on all the targets .
and why the badge says the build is passing
I think you were observing the build result of a branch that was not yet merged. The badge is no longer green now :-).
Thanks for the details. This is great stuff.
- fix emscripten unwinding and unimplemented symbols
- investigate emscripten patch without fastcomp https://github.com/rust-lang/rust/issues/36356
- organize bors-next effort
- follow up on bitcode issue https://github.com/rust-lang/rust/issues/35968
- write typescript / spidermonkey bindings for tokio
- investigate aws deployment and bindings in rust
- implement tuf https://github.com/rust-lang-nursery/rustup.rs/issues/241#issuecomment-253394566
- do 1.13 relnotes
- create beta/nightly testing system for rust projects via travis/appveyor
- maybe inspired by https://github.com/ember-cli/ember-try
- reporting to the mothership
- create list of projects and help authors deploy it
- continue work on platform abstraction layer
- create rust-wasm showcase site (maybe http://www.hellorust.com/emscripten/)
- write some easy fmt rfcs https://github.com/rust-lang-nursery/fmt-rfcs/issues?utf8=✓&q=is%3Aopen%20is%3Aissue%20label%3AE-easy
- make P-high changes - either introduce release milestones or add P-critical
- loosen bootstrap key logic https://github.com/rust-lang/rust/issues/36548
- look at emscripten bug https://github.com/rust-lang/rust/issues/37130
- make issue about reducing giant rustc stacks
Updated op with these. A lot are pretty opaque. Sorry about that.
- write security roadmap
- write release qa checklist
- investigate rustup disk usage during transactions
- change rustup to panic=abort
- write rust packaging guidelines
- get rustup working via powershell one-liner
- add cargo-template quickstart instructions to error-chain docs
- set up static linking for msvc rustc
- fix rustup windows dojob issue (make cargo and rustup use the same dojob code)
- simple crates in need - extract these from rustup/cargo and share
- implement the update framework
- file issue about cap-lints + macro expansion re https://github.com/rust-lang/rust/issues/38977
- fix rust-skeptic resolve bug
- document error-chain backtrace feature
- link rustc statically on windows
- create mostly-Rust userspace from https://github.com/docker-library/busybox
- convert FreeRTOS to Rust
- write LAPACK -> Rust transpiler
What’s this one?
Sounds like you should be able to just run
cargo template quickstart my-new-project and get a project setup to use
I believe my intent was to make https://github.com/brson/error-chain/blob/master/examples/quickstart.rs compatible with https://github.com/pwoolcoc/cargo-template, in anticipation of compatibility with your cargo PR in the future.
Templating was merged into Cargo yesterday.
The following project can be used as a quickstart template (I made a PR to use