Xargo doesn't rebuild std automatically

[1tgr]

See https://github.com/1tgr/xargo-barebones for reference. This repo is a minimal Xargo-based project, with its own std.

Initial xargo build under 'app' works fine.

If you modify libstd/src/lib.rs, then xargo build under 'app' should attempt to recompile 'libstd' followed by 'app'. Instead it does no work and returns straight away. This is clearer if you put invalid syntax in libstd; everything should be rebuilt and fail with an obvious compiler error, but instead it looks like everything worked.

[japaric]

Right, as Xargo main use case is building the rust-src component it doesn't track the state of std's source since rust-src isn't meant to be changed.

(FWIW, I do use Xargo like this, for development of an alternative std, but for I simply put test binaries in the examples directory and built them with xargo build --example $E.)

I'm not sure if I want Xargo to track the state of std's source. That would mean keeping one Cargo project per target in disk.

[1tgr]

I simply put test binaries in the examples directory

Think my situation is more complicated, my std is part of a bigger OS with various libraries and apps built on top. The other libraries and apps each have their own Cargo.toml.

I can develop against my own std by putting std = { path = "../libstd" } into my Cargo.tomls, but that's not an option for dependencies I've taken from crates.io.

That would mean keeping one Cargo project per target in disk.

This doesn't seem too bad...? Taking the equivalent of your examples and promoting them to full projects each with a Cargo.toml.

[SergioBenitez]

Just wanted to chime in and say that I've run into this issue as well. In particular, that xargo doesn't rebuild the relevant stages when std has been modified. I don't see a way to force xargo to rebuild the sysroot, either, unfortunately, so the only recourse I see is to manually rm -rf ~/.xargo.

[thepowersgang]

@japaric (or anyone else) How difficult would it be (implementation wise) to change xargo to track libstd in this manner, probably controlled by a flag in Xargo.toml

I'm willing to put some time towards implementing such a feature (primarily for use in my OS project, similar to @1tgr)

[thepowersgang]

I've (rather hackily) patched xargo to support this feature, see https://github.com/thepowersgang/xargo

Haven't updated the documentation yet, but here's how you activate the new behaviour: (In Xargo.tml)

[xargo]
track-sysroot = true  # Enables maintaining and rebuilding of the sysroot crates
[xargo.stage1]
disable-staged-api = true  # Disables `-Z force-unstable-if-unmarked`