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

Feature examples force explicit listing of all [example]'s #5246

Closed
Xion opened this issue Mar 26, 2018 · 4 comments
Closed

Feature examples force explicit listing of all [example]'s #5246

Xion opened this issue Mar 26, 2018 · 4 comments

Comments

@Xion
Copy link
Contributor

Xion commented Mar 26, 2018

Suppose I have a collection of multiple examples/ in the form of simple *.rs files.

$ ls examples
foo.rs bar.rs baz.rs thud.rs qux.rs

I can expand it & add more example binaries by simply creating a new file inside the examples/ directory:

$ echo "fn main() { println!(\"Hello world\"); }" >./examples/hello.rs
$ cargo run --example hello
Hello world

However, as soon as I want to write an example that requires one of the crate's [features], I have to declare it in Cargo.toml:

[features]
magic = []

[[example]]
name = "do_magic"
required-features = ["magic"]

Unfortunately, this has a nasty side effect: it is now mandatory to explicitly declare all examples in Cargo.toml, whether they require features or not. Otherwise, cargo run --example will not be able to locate the relevant Rust source file, and presumably cargo test will skip over building it, silently.

(I've encountered this issue in my project here).

Is there a reason why [[example]] sections work this way? Wouldn't it be more intuitive if the all examples/*.rs files were interpreted as standalone examples by default, whilst also allowing for an individual [[example]] section to override the properties of a particular example without affecting the auto-detected ones?

@lukaslueg
Copy link
Contributor

Actually, this is true for all targets. Changing this would cause massive breakage for all crates that have examples built from more than one source file, where shared files reside beside examples in /examples.

@matklad
Copy link
Member

matklad commented Mar 26, 2018

Yeah, this behavior defenitelly feels weird to me... On the other hand, we defefenetelly can’t just change it (targets.rs includes all sorts of weird backward compatibility stuff for a reason), and we need to provide some way to opt out of automatic behavior....

I wonder if we could potentially change the way we infer targets in the new epoch?

@Xion
Copy link
Contributor Author

Xion commented Mar 27, 2018

Changing this would cause massive breakage for all crates that have examples built from more than one source file, where shared files reside beside examples in /examples.

I see. I didn't know such sharing was possible. When I needed to share code between different integration tests/, for instance (which AFAIK have the same crate-per-file mechanics as examples/) I used a tests/common subdirectory instead. Otherwise, a tests/shared.rs file would itself be interpreted as another test, which I expect would also happen for examples?

However, if changing the default behavior is not feasible, perhaps we could have an opt-in mechanic where you declare that aside from these specific [[example]]s, you want every *.rs file be picked up automatically by Cargo:

[[example]]
name = "do_magic"
required-features = ["magic"]

[[example]]
name = "*"  # match every remaining examples/*.rs file

This could probably be extended to [[test]]s, [[benchmark]]s, and [[bin]]s.

@matklad
Copy link
Member

matklad commented Apr 9, 2018

Closing in favor of #5330!

@matklad matklad closed this as completed Apr 9, 2018
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

3 participants