Skip to content

Allow to use parallel codegen through build command #1691

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
vhbit opened this issue Jun 8, 2015 · 6 comments
Closed

Allow to use parallel codegen through build command #1691

vhbit opened this issue Jun 8, 2015 · 6 comments
Labels
A-documenting-cargo-itself Area: Cargo's documentation

Comments

@vhbit
Copy link
Contributor

vhbit commented Jun 8, 2015

It's very unfortunate that while parallel codegen landed, it's still impossible to use it directly from cargo build

@alexcrichton
Copy link
Member

This is actually possible with the profiles.*.codegen-units key in Cargo.toml (you can set it to something other than 1), but it's not documented that well, so I'm going to classify this as a documentation bug.

@alexcrichton alexcrichton added the A-documenting-cargo-itself Area: Cargo's documentation label Jun 8, 2015
@vhbit
Copy link
Contributor Author

vhbit commented Jun 9, 2015

Wonderful! Thanks!

@JustAPerson
Copy link
Contributor

When not specified, cargo lets rustc decide, and rustc will default to 1. How should this be reflected in the docs?

# The development profile, used for `cargo build`
[profile.dev]
opt-level = 0  # Controls the --opt-level the compiler builds with
debug = true   # Controls whether the compiler passes `-g`
rpath = false  # Controls whether the compiler passes `-C rpath`
lto = false    # Controls `-C lto` for binaries and staticlibs
debug-assertions = true  # Controls whether debug assertions are enabled
codegen-units = 1 # Controls whether the compiler passes `-C codegen-units`

The above is slightly incorrect because the actual default is None, which in effect defaults to 1.

@alexcrichton
Copy link
Member

Ah it's fine to just have some placeholder like ... and explain the default in a comment

@huonw
Copy link
Member

huonw commented Jun 11, 2015

This is actually possible with the profiles.*.codegen-units key in Cargo.toml (you can set it to something other than 1), but it's not documented that well, so I'm going to classify this as a documentation bug.

Hm, it's extremely non-obvious to me why this makes sense in a per-project Cargo.toml: it seems to me that usually people will want codegen-units = num_cpus() for dev builds and = 1 for others (i.e. global constants specific to a single machine, not to a published project), and most other values would also be set globally on a machine e.g. maybe someone using a 32-core machine wants to "rate limit" rustc to only 4 cores.

@alexcrichton
Copy link
Member

@huonw hm that's true, I initially thought that it was closely related to the optimization level of a crate (which seems appropriate in a profile), but it may be more of a .cargo/config option instead of a Cargo.toml option.

That being said, I think that most crates won't bother with this key and will instead on the compiler choosing a nice set of defaults.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation
Projects
None yet
Development

No branches or pull requests

4 participants