vcpkg in Mudlet

[vadi2]

We've been building an open-source client to play online text games with (https://github.com/Mudlet/Mudlet) for a good decade now with C++, Qt, and Lua on Windows, macOS, and Linux.

vcpkg is the first C++ package manager we're dipping our toes into - and the experience has been quite good; we've been able to get about half of our dependencies via it. The rest still need complementing from native package managers which we'd like to move away from for easier maintenance (see workflow).

These days we're using C++17, Github Actions, and Appveyor as part of our toolstack. Clang/GCC power the builds on Linux/macOS and we continue that trend on Windows by using MinGW-64; the latter was initially a blocker but since vcpkg has adopted it on a community basis, we've had little issues with using it.

Where it could be better is support for particular versions of a portfile - we have to maintain Lua 5.1 ourselves, and that's not ideal if you want your port to be up to date with changes in the ecosystem. Easier bootstrapping of vcpkg would also be welcome - we haven't yet replaced PowerShell scripts that set up dependencies with it. I understand there's upcoming Visual Studio integration, but in this case, it's not an IDE we use - Qt Creator and CLion are the favorites here.

run-vcpkg and its companion action run-cmake by lukka have been essential in our adoption as it greatly simplifies the build process and provides automatic caching out of the box.

All in all, it feels nice to be using a C++, CMake-based package manager, and happy to be part of the community. Thanks for all the work the vcpkg team is doing!

[AugP]

Thank you for sharing your story! I'm glad you're finding vcpkg a good fit for your workflow.

For sticking to a specific port version, have you taken a look at our new versioning support? It's currently experimental, but it may be able to help. You will also need to use a vcpkg.json to get that set up. Docs are here: https://github.com/microsoft/vcpkg/blob/master/docs/users/versioning.md

For bootstrapping, we may be able to create a better experience. As part of the work to create vcpkg extensions for Visual Studio and Visual Studio Code, we need to have prebuilt binaries of the tool available. We may be able to distribute those binaries more broadly than just for those environments. The main thing holding us back is some additional legal/security compliance work, plus we weren't sure how popular that acquisition model will turn out to be. This is good feedback for us, thank you!

Are there any ways vcpkg could have better GitHub integration in your view? We have been thinking about GitHub Actions and GitHub Packages and if that's something we could leverage in the future. +1 on Lukka's actions; they have also been helpful for us in our demos of the tool.

[vadi2]

versioning support

I have not seen, thanks for that. How do we go about using it for Lua 5.1? Would #7713 need to be solved first?

We may be able to distribute those binaries more broadly than just for those environments.

I think that would be great. Thanks for considering it!

We have been thinking about GitHub Actions and GitHub Packages and if that's something we could leverage in the future.

I think that would be great. Lukka's actions work great and having an official presence would compliment it well.

One thing I forgot to mention - a particular pain point for us was using header-only Boost. We only use Boost.Graph which requires no compilation, and vcpkg doesn't quite support that. Used vcpkg+Boost initially but the long compile-times are offputting (15min), and since Github Actions clear the cache frequently, this price wasn't exactly "do it once and forget". Ended up switching from vcpkg to a simple shell script that downloads and unzips Boost instead.

Thanks for listening to feedback!

[mathisloge]

Github Actions clear the cache frequently, this price wasn't exactly "do it once and forget". Ended up switching from vcpkg to a simple shell script that downloads and unzips Boost instead.

I've not used lukka instead just used vcpkg directly inside the workflow which was also quite easy to setup + binary caching as nuget. With the binary caching you only need to recompile the consumed libraries if vcpkg itself got updated.

https://github.com/mathisloge/device-tester/blob/master/.github/workflows/cmake.yml

https://github.com/mathisloge?tab=packages&repo_name=device-tester

The base of the workflow was published from @AugP at https://devblogs.microsoft.com/cppblog/vcpkg-accelerate-your-team-development-environment-with-binary-caching-and-manifests/

[nightlark]

One thing I forgot to mention - a particular pain point for us was using header-only Boost. We only use Boost.Graph which requires no compilation, and vcpkg doesn't quite support that. Used vcpkg+Boost initially but the long compile-times are offputting (15min), and since Github Actions clear the cache frequently, this price wasn't exactly "do it once and forget". Ended up switching from vcpkg to a simple shell script that downloads and unzips Boost instead.

This is the exact same issue I currently have with vcpkg that makes me hesitant to recommend it as a way to set up a development environment for HELICS. We use several Boost libraries, but we only use the header-only portion of those libraries.