vcpkg and why I like it

[George P]

vcpkg is a package manager, created and maintained by Microsoft and usable on Windows, Linux and MacOS.

https://vcpkg.io/en/index.html

It is especially useful for Windows and Visual Studio since the managed library packages can be integrated into VS so there is no need to add header/lib directories to use the packages.

I currently have 624 packages, most of them are the boost libraries as individual modules. 3 different versions of the libraries so I can have x64, x64-static and x86 compatible setups.

vcpkg makes libraries with dependencies easy to maintain, using Git. Once vcpkg is installed an update is:

1. Start a Command Prompt and navigate to the vcpkg directory.

2. 'git pull' retrieves any new updates.

3. 'vcpkg update' shows what libraries have updates, at least what updates have been added to the vcpkg database.

D:\Programming\vcpkg>vcpkg update
Using local portfile versions. To update the local portfiles, use `git pull`.
The following packages differ from their port versions:
    egl-registry:x64-windows         2021-11-23 -> 2021-11-23#1
    sdl2:x64-windows                 2.24.0 -> 2.24.1
    vcpkg-cmake:x64-windows          2022-09-13 -> 2022-09-26
    vcpkg-cmake-get-vars:x64-windows 2022-05-10#1 -> 2022-09-04

4. to update the installed libraries, including ones that are inter-dependent use the upgrade command.

vcpkg upgrade --no-dry-run >>install.txt

(I pipe the command prompt's output to a text file, appending the output to the end of the file so I have continual documentation of what I've upgraded.)

In this upgrade instance there were 4 packages that had updates. vcpkg upgraded over 100 packages because of dependencies.

I started the upgrade and let vcpkg do its magic.

Total elapsed time: 3.648 h

RESULTS
    (elided for space, there were a LOT of entries)

SUMMARY FOR x64-windows
    SUCCEEDED: 109
    REMOVED: 109
SUMMARY FOR x64-windows-static
    SUCCEEDED: 104
    REMOVED: 104
SUMMARY FOR x86-windows
    SUCCEEDED: 107
    REMOVED: 107

Yes, over 3 1/2 hours, mostly because the Boost libraries had to be updated as well, but I didn't have to worry that any dependent library wasn't properly maintained. No manual updates worries or hassles.

When the updating is done I then create a list of my installed libraries.

vcpkg list >list.txt

While composing this post I did another check for library updates and vcpkg had more. A single library, python 3, that is currently doing 24 upgrades to itself and other dependent libraries, 8 12 total libraries, 3 different versions. x64, x64-static and x86.

[George P]

D:\Programming\vcpkg>vcpkg update
Using local portfile versions. To update the local portfiles, use `git pull`.
The following packages differ from their port versions:
    python3:x64-windows              3.10.5#3 -> 3.10.5#4

To update these packages and all dependencies, run
    .\vcpkg upgrade

To only remove outdated packages, run
    .\vcpkg remove --outdated

One package to update, with dependencies 3 more.

The following packages will be rebuilt:
  * boost[core]:x64-windows -> 1.80.0#1
  * boost[core]:x64-windows-static -> 1.80.0#1
  * boost[core]:x86-windows -> 1.80.0#1
  * boost-parameter-python[core]:x64-windows -> 1.80.0
  * boost-parameter-python[core]:x64-windows-static -> 1.80.0
  * boost-parameter-python[core]:x86-windows -> 1.80.0
  * boost-python[core,python3]:x64-windows -> 1.80.0
  * boost-python[core,python3]:x64-windows-static -> 1.80.0
  * boost-python[core,python3]:x86-windows -> 1.80.0
  * python3[core]:x64-windows -> 3.10.5#4
  * python3[core]:x64-windows-static -> 3.10.5#4
  * python3[core]:x86-windows -> 3.10.5#4

Time from start to finish:

Total elapsed time: 26.52 min

vcpkg gives a nice break-down for each updated library the amount of time needed to complete the update.

[Geckoo]

Useful. Thanks for the tips ++

[George P]

To use vcpkg requires a git client. "Git for Windows" is the one I use.

https://gitforwindows.org/

[Geckoo]

And this way, using Git For Windows, you can automate all packages update. Clever tool ++

[George P]

Well, not 100% automated. The process of updating the installed packages is automated by the package manager, initiating the package manager process still requires being done manually.

I'm sure someone could cruft a batch file to really automate the process, though I'd never use it. A bit of manual typing and I get to choose to upgrade or not, if there are updates.

[Geckoo]

I understand. It is more or less like $ sudo apt upgrade, but specifically for your packages on Windows. A batch could simplify process. Really neat tool ++

[George P]

MSYS2 with its package manager is even easier to keep up-to-date.

MSYS2 uses a Windows version of the Mintty Bash shell, to update the compiler and any optionally installed libraries is as simple as: pacman -Syu.

Lather, rinse, repeat that single command until there are no more current updates.

[helios]

Do you use vcpkg as a RAD tool, or for bigger projects also? For throwing something together a package manager is neat, but for long-term maintenance I want to have complete control over my dependencies; if possible and practical, I bring everything into the tree and add it to my build process.

[George P]

I use vcpkg as a package manager; makes adding, updating and uninstalling 3rd party libraries less of a PITA. Any dependencies with other 3rd party libraries are taken care of by vcpkg.

As updates become available for an installed library doing a manual check for updates and manually initiated upgrade and vcpkg takes over the build process. vcpkg will build the libraries as needed so installed libraries have updated .lib files if the library uses them.

The integrate feature available for Visual Studio makes it easy to use installed libraries, as painless as using the MSVC++ libraries and headers. No "oh, shit, I forgot to add that 3rd party paths to my project's paths" settings.

Say I want to use the one of the Boost libraries, VS can search and auto-fill the header filename(s) as I type my #include <>, the same for the VS native C/C++ libraries. The 3rd party's .lib files are added seamlessly to the project without having to manually modify the project's library/header paths.

I use vcpkg because I don't want to have to hunt down any dependencies a library I want to use might have. If I install the JKL library and it is dependent on other libraries I haven't already installed it will retrieve those libraries and install them as well.

I use vcpkg so I don't have to modify a project's paths settings manually.

Other compilers and other OSes can use CMAKE, when a library is installed the CMAKE command is given in the install output.

[helios]

adding

Adding libraries is annoying, I'll give you that.

uninstalling

I just delete the files.

updating

There's no silver bullet for this. Updating dependencies is always going to suck, because there's no telling how any of your dependencies might have changed their interfaces or their semantics. You're going to love vcpkg until the day you run into version hell and your project no longer builds, and you need to figure out either how to gather and build the right versions of your entire dependency DAG, or the right incantation to give to vcpkg to get to fetch the right versions of subdependencies. And god save you if you run into the situation that after updating, two of your dependencies require mutually incompatible versions of the same library.
I know, because I'm currently dealing with this sort of situation with Cargo.

A package manager is great during development. You can try different libraries out to see how they work without investing a lot of time. It absolutely sucks once you put your code in the freezer, and doubly so if you need to rebuild months or years later.

I use vcpkg because I don't want to have to hunt down any dependencies a library I want to use might have.

Unfortunately this is like saying that you use a credit card because you don't want to pay for your lunches. It only works if you're going to drop dead before the end of the month.

Say I want to use the one of the Boost libraries, VS can search and auto-fill the header filename(s) as I type my #include <>, the same for the VS native C/C++ libraries. [...] I use vcpkg so I don't have to modify a project's paths settings manually.

I just download and build them. I have the installation directory added as a global include and library directory for VS, since Boost is something I may want to use frequently. Why would I need a separate tool for this when it's already a feature of the compiler?

[George P]

I just delete the files.

And if the library files you've just deleted were a dependency for another installed library? Either you broke the library or have to rebuild it to compensate for the no longer available dependency.

vcpkg does that for me. Ease of use.

I used to manually download and build 3rd party libraries, Boost being the biggie, and for me trying to get a 3rd party library to work was a major PITA. I spend far too much time trying to get the library to work and usually ended up in failure. Boost was one library that actually worked for me after spending a lot of time with failure after failure.

A package manager is great during development. You can try different libraries out to see how they work without investing a lot of time.

That is my workflow in a nutshell. I dabble, and dabble and dabble as a hobby.

I'm not a professional programmer, I'm a self-taught hobbyist. Nothing else, with no aspirations of coding for a living.

I prefer what I see as ease of utility vcpkg offers for dealing with 3rd party libraries. It works for me for the workflow I do. Which ain't much. My code usually doesn't require a long term shelf-life beyond a couple of days or hours.

Is vcpkg perfect? No. Nothing created by humans is. But for my needs it works in reducing the manual overhead of working with 3rd party libraries.

The ease of use could be illusionary, but it is something I can live with. It comforts me in my old age.

YMMV. You do what works for you.

[helios]

And if the library files you've just deleted were a dependency for another installed library?

I don't share dependencies across unrelated directory trees. If a compiled library has dependencies then they should all be in the same tree, even if that means some files are going to be duplicated. Most libraries aren't so big that this is an issue.