"default-features":false seems to just be ignored. Feature selection always adds default-features #35694
Comments
|
|
|
Thanks for the reply, Alexander
I'm not an English language expert and not a native speaker, but to me if that's correct, then the docs with "If the user wants to explicitly disable the default features, they can do so by adding
Do I get you right, that if I want |
It is enough to say you want ffmpeg with Also there is nothing more to document. The docs already say:
|
|
@Arech In actual testing, this function is normal and it does disable the build of the default features.
|
|
vcpkg/ports/tinyorm/vcpkg.json Line 31 in 50bffcc
|
FrankXie05
added
category:vcpkg-bug
This is right. In port manifests, it declares a possibility and enables user choice. The actual control is only in user project manifests (or at the command line using pseudo feature |
|
That's a bit confusing... I think I haven't seen that difference mentioned in ports creation documentation, but now I understand it better. Probably should be said somewhere more explicitly... Anyway, thanks a lot everyone involved and have a great weekend! |
|
(and a personal thanks to @FrankXie05 for spotting the issue) |
|
Currently, I can confirm that this feature is indeed broken. (either from the configuration parameters passed or the actual installed dependencies). When @JavierMatosD @BillyONeal Could you please help take a look? |
@FrankXie05 please explain what is broken, given the expected behavior presented in |
|
Erm... Here's another test that shows that App manifest file explicitly prohibits {
"$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
"name": "myapp",
"version": "1",
"vcpkg-configuration": {
"$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg-configuration.schema.json",
"default-registry": {
"kind": "git",
"repository": "https://github.com/microsoft/vcpkg",
"baseline": "000d1bda1ffa95a73e0b40334fa4103d6f4d3d48"
}
},
"features": {
"common-opencv-port": {
"description": "A single common for the whole repo port of OpenCV",
"dependencies": [
{
"name": "opencv4",
"default-features": false,
"features": [ "jpeg" ]
}
]
},
"irrelevant-feature": {
"description": "heavy ports just for testing, they shouldn't be used",
"dependencies": [ "opencv3", "opencv2" ]
},
"myfeature": {
"description": "will use this feature only. common-opencv-port might be a dependency of many other features of this app",
"dependencies": [
{
"name": "myapp",
"default-features": false,
"features": [ "common-opencv-port" ]
}
]
}
},
"dependencies": []
}CMakeLists.txt to choose which feature to use depending on build settings cmake_minimum_required(VERSION 3.16)
# choosing feature list (depending on some CMake vars in a real project)..
set(VCPKG_MANIFEST_FEATURES "myfeature")
# trigger vcpkg
project(MyTestProj)I expect it to use only `"jpeg" feature of OpenCV4 port. Now run and observe what vcpkg starts to build: vcpkg ignores requirement to use only explicitly specified features and use all defaults instead. And it's not that it shows it wrongly, it really starts to build every other damn feature I don't need. The same behavior I see on Ubuntu 20.04 @ WSL You can clone https://github.com/Arech/vcpkg_default_features repo with that code If I'm doing something wrong here, please advice me on how to modify the code to make it only use explicitly specified features? Current behavior brings enormous toll on our CI and on local devs... |
No, I think you provided a small reproducible example to prove the bug. 💣
I didn't test with CMake but with |
I don't need to run it to confirm your guess, as I see it regularly in the projects I deal with. Yes, referencing a feature directly will make vcpkg to respect Assuming that the same code in vcpkg handles feature aggregation for top-level manifests and for ports, it looks like handling of features is somewhat broken for anything but directly and externally requested features. Features of a port dependency (such as I described in the first message) are never requested directly, hence To me the explanation of |
It is a fair requirement for some use cases, and there is much support for adding an option to enable such a minimal-dependencies mode. And there is microsoft/vcpkg-tool#538 which still doesn't seem to get enough interest from Microsoft.
Doesn't installing minimal features just have the effect of forcing users to know and request all the features which they would expect to be generally included? |
There are several things to unpack here. (1) I don't propose to force always installing minimal features. I think that current system that have some features enabled by default and a machinery to fully customize features are ideal and probably can't even be improved. I just want vcpkg to respect it's own settings, because actually the current approach (ignoring (2)
I think the answer is definitely no and here's why:
(3) The last but not the least, why ignoring Many ports depend on dependencies that are fully external to vcpkg. Be it a platform SDK, system installed packages, or some specific user installed software, - most, if not all, non-trivial ports depend on it. These external dependencies gets updated on it's own schedule and vcpkg does great job on tracking dependent files change, and forcing recompilation of ports that depend on changed files. This is not very frequent on Windows, though even there a compiler might be updated a couple of times per month (requiring to recompile everything), but on Linux... it's a real pain on Linux, because the amount of system dependencies in form of source code is huge, and a system might get several updates per day. Not all these updates are in a dependency chain of some used port, but some of them are. We have quite a modestly sized project depending on boost and opencv ports and due to this, vcpkg has to rebuild many ports several times a week. This takes up to a dozen of minutes locally (multiply that by the number of developers affected) and then there are Azure CI agents that are less powerful than local workstations and depending on amount of changes, sometimes CI jobs even timeouts of an allocated hour of working time. This time is also wasted, because oftentimes developers depend on their PR to get merged before they can proceed further. So all of this stack up to a huge amount of wasted time for the company. |
|
Ah, and there's another major independent reason why ignoring |
Understood. But the interpretation of
Agreed, with regard to "installed". But AFAIU the main purposes of "default-features" is not to install dependencies but to provide typical (but optional) capabilities. Like the most common compression modes in Maybe that's the key problem: Most of us want minimal dependencies. But what is offered for control are features. Most of us also want less rebuilds. But the immediate control is to pin versions, not the interpretation of
|
HDF5 is challenging in all cross-builds. Upstream wants you to detect properties from your target runtime and feed them in at build time. |
Yes, it was a bad phrasing on my side. By "installed" I meant not just installing binary tools, but primarily making additional headers available for inclusion and libraries/entry points into libraries to linking to for the port affected. These additional capabilities usually in the essence are just some additional code a vcpkg user could rely on in a transparent manner. Anyway, we seems to agree on the definition of the problem. How can I ping people, who make the decisions that we need here? Who are they and how to reach them? This problem is really huge damn pain in the a*s for me personally and for my company... |
|
BillyONeal
added
the
requires:tool-release
BillyONeal
removed
the
requires:tool-release
|
I just did a I've got a package that I want to depend on opencv4 but not on its default features (because it essentially just needs As far as I understood this thread, there should be a way of installing my-test-package with its opencv4 dependency without default features? How do I do that? If I do on the command-line: Am I misunderstanding this thread, or is this still not possible, or am I doing something wrong? (The difference in build-time, dependency size etc. between |
You ("user") must ask for it in the command line or in the your "top-level" manifest. (The port manifest is just an enabler.) Command line example: |
Describe the bug
I might misunderstand something in vcpkg, but I though that according to the docs,
"default-features": falseshould totally disable default feature set defined for a port and install only explicitly selected features. But it's not the case. Default-features are always selected and installed.I have a private repository containing two ports:
Xwith two features:heavyAandlightB, and"default-features": [ "heavyA" ].Ywith several features, one of which, say"featureB"hasI assumed that when manifest contains a dependency on port
Y[featureB], then vcpkg must also install portXwith featurelightBonly, b/c default features, containingheavyA, are disabled. However, when building a software I noticed that portXinstalls both features, -heavyA(that should be disabled) andlightB. I've double checked everything and I can't find any potential source of dependency on featureheavyAof portXanywhere.I was able to replicate that with publicly available ports:
opencv4 port contains a spectra of default-enabled features.
opencv4hasffmpegfeature defined in a similar manner with restricted feature set:By default ffmpeg port has these default features:
So I assume that when I install
opencv4[ffmpeg]only 4 specifically selected by opencv4 manifest's features must be present. However, it's not true:i.e. vcpkg fetches all default features for
ffmpegplus those additionally specified, and foropencv4it also selects all default features plusffmpegfeature as an addition, instead of using it exclusively.(
depend-infocommand is used to demonstrate the issue, the same is happening when vcpkg really install ports)This seems like a bug to me. Documentation clearly states:
(see the bottom of the page)
Do I misunderstand something?
Environment
The same results in Windows 10:
as well as on Ubuntu20.04 (in WSL with own vcpkg checkout, which hardly matters..)
The text was updated successfully, but these errors were encountered: