Best practices with vcpkg?

1

Is anyone using vcpkg to help manage their external dependencies? Previously if I was writing a block that used a third-party library (websockets, curl, mqtt, etc.) then I’d just include the library as a submodule. That said, getting the library to build was oftentimes a hassle. I’ve had really good luck with using vcpkg so far; pretty much every library I want to use just works out of the box. I’m trying to sort out what are the best ways to use it to manage libraries across projects, and figured I’d reach out to the community to see if anyone has a good system already!

1 Like
2

An update on my own personal practices:

It turns out that the versions of various ports that you can download (e.g. the exact version of asio, mqttpp, etc.) are linked to a specific git commit of vcpkg. So what I’ve been doing is tracking vcpkg as a submodule, just like cinder. My folder structure generally looks like:

myProject/
    dependencies/
        cinder/
        vcpkg/
        myCinderBlock/
        anotherCinderBlock/
    projects/
        myApplication/
    vcpkg.json

where vcpkg.json is a vcpkg manifest file. Each of the files in dependencies is its own submodule, so each one gets tracked separately, and I just updated the manifest file depending on what external libraries I need for the various cinder blocks I’m using. This has been working for me pretty well so far, though again I’d love to hear if anyone else has a system they’ve been using that works better!

1 Like