Enable writing custom profiles #601
Comments
|
Could you elaborate a bit more on what you mean by a custom profile? Are you thinking something like: [profile.my-profile]
...and then |
|
Maybe? I don't really know much about Cargo, and @metajack suggested that custom profiles might be a solution. I just want a way to provide developers with choices about certain aspects of the build beyond all optimized or all debug. |
|
We also need this for skia. The old configure had --enable-skia-debug which would turn on Skia debugging which is extraordinarily expensive (it calls glGetError() after every call). You almost never want that in a debug build, except when you are debugging certain graphics problems. |
|
The only other solution I can think of is to use environment variables that the Makefile.cargo's trigger off of, but that doesn't help when we want to make these kinds of decisions in crates instead of C libraries. |
|
@alexcrichton mentioned we may be able to use --feature and pass the features down explicitly to subcrates and use that. |
|
Features almost work for this (with a patch to add environment variables that can be accessed in native build commands), but they're not propagated to dependencies at the moment. We're back at no solution right now. |
|
Do profiles propagate? If so, it sounds like my original request would be an acceptable short-term fix while we sort out the future of features. |
|
@jdm not currently. After thinking more I don't think that features are sufficient for this use case, although I believe they should be. I'm going to talk more with @wycats about the design of features soon. Profiles do propagate, but the configuration for a profile always comes from the top-level package. |
|
Ah, when I say "not currently", I actually mean that features do not currently work, not that profiles do not propagate. Words! |
alexcrichton
added
the
A-linkage
Closes rust-lang#97 Closes rust-lang#601 (this is an equivalent solution for that problem)
As pointed in #633, it's currently not possible for a package to reexport the feature of another package due to the limitations of how features are defined. This commit adds support for this ability by allowing features of the form `foo/bar` in the `features` section of the manifest. This form indicates that the dependency `foo` should have its `bar` feature enabled. Additionally, it is not required that `foo` is an optional dependency. This does not allow features of the form `foo/bar` in a `[dependencies]` features section as dependencies shouldn't be enabling features for other dependencies. At the same time, this passes through features to build commands to solve a few more issues. Closes #97 Closes #601 (this is an equivalent solution for that problem) Closes #633 Closes #674
For Servo, I'm interested in allowing developers to build either debug or opt builds of a native submodule. I can nearly get there by matching on the
PROFILEenvironment variable in the makefile, but there's no way to specify arbitrary custom profiles for Cargo.The text was updated successfully, but these errors were encountered: