Can't find crate for alloc

[thejpster]

I've updated to Xargo 0.3.2, but github.com/thejpster/launchpad-rs won't build any more.

Do I need a Xargo.toml file to get it to build alloc and collections? Target is

1 ✗ jonathan@cobalt ~/Documents/programming/launchpad-rs
$ xargo build --example launchpad_blink
Building launchpad_blink...
warning: `build.rs` files in the same directory as your `Cargo.toml` will soon be treated as build scripts. Add `build = false` to your `Cargo.toml` to prevent this
   Compiling gcc v0.3.41
   Compiling rlibc v1.0.0
   Compiling linked_list_allocator v0.2.3
   Compiling r0 v0.1.0
   Compiling embedded-serial v0.3.0
   Compiling rustc-cfg v0.3.0
   Compiling volatile-register v0.1.2
   Compiling spin v0.4.5
   Compiling cortex-m v0.1.5
   Compiling lazy_static v0.2.2
   Compiling alloc-cortex-m v0.2.1
   Compiling lm4f120 v0.2.0
   Compiling compiler_builtins v0.1.0 (https://github.com/rust-lang-nursery/compiler-builtins.git#764557f0)
   Compiling launchpad v0.5.4 (file:///home/jonathan/Documents/programming/launchpad-rs)
error[E0463]: can't find crate for `alloc`
  --> examples/launchpad_blink.rs:16:1
   |
16 | extern crate alloc;
   | ^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

error: Could not compile `launchpad`.

To learn more, run the command again with --verbose.

[thejpster]

See https://travis-ci.org/thejpster/launchpad-rs/builds/189023117 vs https://travis-ci.org/thejpster/launchpad-rs/builds/177333647

[japaric]

Do I need a Xargo.toml file to get it to build alloc and collections?

Yes. Something like this:

[target.thumbv7em-none-eabihf.dependencies]
collections = {}  # implies alloc

[thejpster]

Yup, that's done it. Thanks.

[Earlz]

I tried the collections trick, but just get:

error: no matching package named collections found

I'm using a custom target. Is there some new way of doing this?

[RalfJung]

The collections crate doesn't exist any more for... ages.

What's your Xargo.toml?

[Earlz]

The collections bit was the only thing I could find when searching for the problem. The more recent answer I found said they fixed it by switching to cargo xbuild, and so I spent 5 minutes switching to that which seems to fix all that and in general feels a bit less hacky for my use case. The only thing I wish is that there was an equivalent cargo xtest for cross compiled testing within a VM/test runner