cargo clean doesn't clean components/ crates

[fabricedesre]

ping @JohanLorenzo @samgiles

[samgiles]

Hmm, maybe a top level Makefile would be useful? 😬

[fabricedesre]

Well, see also #424

[JohanLorenzo]

This is likely due to the fact that cargo deals with one target folder. At some point, this is planned to change: build workspace are being RFC'd rust-lang/rfcs#1525. Servo builds with mach, so I think we could either go with it or with a Makefile.

[julienw]

I guess the issue is again about ./components/dns_challenge ?
Note I filed rust-lang/cargo#2573 some time ago, you can comment there with this new use case if you think this could be useful.

But both this bug and #424 seems to show that this is maybe not the right directory structure for ./components/dns_challenge as it's not a lib but a runnable binary. Cargo is not very good at handling several binaries, and that's the root issue here.

[julienw]

Actually, adding this to foxbox' Cargo.toml:

[[bin]]
name = "foxbox"
path = "src/main.rs"

[[bin]]
name = "dnschallenge"
path = "components/dns_challenge/main.rs"

fixes both this bug and bug #424 for me. (I removed the call to "cargo_build_in_directory" in build.rs).

This will generate both dnschallenge and foxbox binaries in target/debug. And this seems to react appropriately to cargo clean and cargo build when something changes in subdirectories.

Now of course we need to make this work properly since the dnschallenge binary is not located in the same place.

[samgiles]

Nice! It doesn't matter where the binary is located, as long as it's on the PATH.

[julienw]

PATH=target/debug:$PATH cargo run --bin foxbox works pefectly with this PR ^ :)

Yet the command line is not so nice. Maybe a simple "start.sh" script could make this easier.