Replies: 3 comments
-
We've implemented single package exporting (including dependencies), which works and deals with most issues: master...invym:master Implementation is based on: #2527 |
Beta Was this translation helpful? Give feedback.
-
@invy 1. I understand the shared dependency issue, but in my experience, many authors of C and C++ libraries try to minimize their dependencies.
P.S. In our team nuget packages is the only reason why I’m still trying to use vcpkg. At least this way I’m the only person spending time building them and fixing numerous port bugs. If every C++ developer would have to do what I’m doing, I would have banned vcpkg usage in our team long ago, it takes too much time due to usability issues like this and many others you don’t want to fix (like the default 32-bit build target). |
Beta Was this translation helpful? Give feedback.
-
@Const-me you could try our implementation, it works for us, the only reason we didn't file a PR is CLA. The one thing we didn't do is automatically assign version... because of versions of packages (it just didn't fit anywhere for bunch of packages), so for us the version is the part of ID and nuget package version either defaults to 1.0.0 or we can specify it. |
Beta Was this translation helpful? Give feedback.
-
When I run
./vcpkg export <single package> --nuget
the output file name defaults tovcpkg-export-<timestamp>.1.0.0.nupkg
Instead, it should default to
<package><version>.nupkg
I've passed package name to the command line argument. Packages have versions in their CONTROL files. You already have good default values for both --nuget-id and --nuget-version parameters.
Beta Was this translation helpful? Give feedback.
All reactions