Replies: 2 comments
-
|
Another alternative approach to solve this issue could be to extend the manifest file format with an option to add custom variables, which later map to prefixed CMake variables. What about something like this:
{
"name": "name",
"version-string": "1.0.0",
"dependencies": [
(...)
{
"name": "zlib"
},
{
"name": "ffmpeg",
"build-settings": {
"dynamic": 1
}
},
(...)
]
}
set(VCPKG_LIBRARY_LINKAGE static)
if(PORT_BUILD_SETTINGS_dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)
endif() |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
See discussion in microsoft/vcpkg-tool#596 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm currently working on integrating vcpkg into a large project. For various reasons I require some packages to be built as shared, others as static libraries. For this I follow the recommendation from the docs by using a custom triplet overlay file containing per port customizations. My problem is that with any change in my custom triplet file I get a full rebuilt for everything, which takes ages due to the large number of packages (~400, including OpenCV and other long building packages).
As far as I understand the internals of vcpkg, port files can only change a predefined set of variables. If so, wouldn't it be smarter to hash the values of these variables in a fixed order? This way, if I add another library to the list of packages to be dynamically created, I would not only save a lot of time, but also tons of space in my binary cache, since right now I have near-duplicates for every package with different filenames:
When diffing the content of any of such near-identical ZIP files I only find different hash values in files like
CONTROLorvcpkg_abi_info.txt.Is there a better way to choose per package between static and dynamic configuration?
Beta Was this translation helpful? Give feedback.
All reactions