-
Notifications
You must be signed in to change notification settings - Fork 288
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
Implement depend-defaults #295
Implement depend-defaults #295
Conversation
Port {
"name": "test1",
"version": "1.0.0",
"default-features": ["foo"],
"features":{
"foo": {
"description": "bar"
}
}
} Main {
"name": "root",
"version": "1.0.0",
"depend-defaults": false,
"dependencies": [
{
"name": "test1",
"default-features": true
}
]
} Results in
Imho it should install |
The problem is that the |
Can you merge with main? |
Are you still working on this? If not I think we should close the PR. |
I have completed this PR in #538. One thing: The features vector now always contains "core" which seems a little bit unnecessary. |
Closing this in favor of #538 |
This manifest property implements two highly requested features:
Sets the default for "default-features" in the current manifest to false, meaning a simple dependency list of strings will not imply dependency upon default features. The vast majority of dependencies should not require defaults, so this avoids the boilerplate of explicitly qualifying every dependency as
"default-features": false
.If used in the top level manifest, disables automatic addition of defaults for transitive unnamed dependencies. This enables easier testing of the "minimum set" of dependencies and has been commonly requested by advanced users of vcpkg.
Edit:
During the implementation of this feature, I ran into an issue where the code reuses
Dependency
both as a context sensitive parse tree as well as a context-free representation of dependence in the version resolver algorithm. I've chosen to resolve this in the simplest way possible for now (inject the context in theSourceControlFile
parser), however the more correct long-term approach is to introduce a separate representation for the context-free form (that has anInternalFeatureSet
, etc).