conan VS Vcpkg

Conan is a package manager for C/C++. See: https://conan.io/.

The way it works is that you can provide "recipes", which are Python scripts, that automate the process of collecting source code (usually from a remote Git repository, or a remote source tarball), patching it, making its dependencies and transitive dependencies available, building for specific platform and architecture (via any number of build systems), then packaging up and serving binaries. There's a lot of complexity involved.

Here are the two recipes I mentioned:

libcurl: https://github.com/conan-io/conan-center-index/blob/master/r...

OpenSSL v3: https://github.com/conan-io/conan-center-index/blob/master/r...

Now, for the sake of this thread I want to highlight three things here:

- Conan recipes are usually made by people unaffiliated with the libraries they're packaging;

- The recipes are fully Turing-complete, do a lot of work, have their own bugs - therefore they should really be treated as software comonents themselves, for the purpose of OSS clearing/supply chain verification, except as far as I know, nobody does it;

- The recipes can, and do, patch source code and build scripts. There's supporting infrastruture for this built into Conan, and of course one can also do it by brute-force search and replace. See e.g. ZLib recipe that does it both at the same time:

https://github.com/conan-io/conan-center-index/blob/7b0ac710... -- `_patch_sources` does both direct search-and-replace in source files, and applies the patches from https://github.com/conan-io/conan-center-index/tree/master/r....

Now, good luck keeping track of what's going on there.

There were various approaches recommended depending on our language and ecosystem. My classmates who developed using Node.js were recommended npm, and PyPI or poetry for Python. Since my program is written in C++, I was recommended to look into one of vcpkg or conan, but I ultimately did not use either package manager.

Hi u/instinkt900, Conan maintainer here. Thanks for your feedback! Please remember that we actively monitor and respond to our issue tracker on GitHub (https://github.com/conan-io/conan/issues/new/choose), we’d love to hear about your specific use cases or pain points, so that we can improve your experience and that of other users. The motivation behind most of the updates in Conan 2.0 was precisely feedback from the community, and to improve our ability to continue delivering features in the constantly changing C++ ecosystem. We can certainly do this at a quicker pace, with some exciting new features recently released and in the pipeline: package metadata, transparent backup of downloaded package sources, cache least-recently-used cleanup, etc. A lot of the big decisions that we took for Conan 2.0 were taken with consensus from expert users and contributors (https://conan.io/tribe) and https://github.com/conan-io/tribe. Some specific workflows may not have 1:1 replacements in Conan 2.0, and are likely to affect some of the “less travelled roads” of Conan 1.x, including some features that were always marked as experimental. We are happy to hear feedback so that we can best satisfy these use cases. Conan 2.0 also includes a more sophisticated API to cover cases where the built-in integrations may not satisfy users needs. For what it’s worth - we have also heard very positive feedback from users about how Conan 2.0 simplifies their workflows when compared to Conan 1.x. The C++ tooling ecosystem is fragmented and moves at different speeds, including our users. So it’s always a fine balancing act, but we don’t want to leave anyone behind! An example is Conan Center - over 90% (~1200) of all recipes have been migrated to support Conan 2.0, while still maintaining compatibility with Conan 1.x, precisely to avoid breaking users that are still on Conan 1.x.

The closest thing we have at the moment is conan[1]. It’s a cross platform package manager that attempts to implement “toolchains”, whereby different build systems can be integrated[2]. This is a big problem with package management in C/C++, there’s no single, standardised build system that most projects use. There isn’t even a standardised compiler! So when hosting your own packages using Conan, often you need to make sure you build your application for three different compilers, for three different platforms. Sometimes (for modern MacOS) also for two different architectures each.

If you control the compiler AND build system you can get away with just one package for most cases. This true for Microsoft’s C/C++ package manager, NuGet[3]

Historically, the convention has been to use the package manager of the underlying system to install packages, as there are so many different build configurations to worry about when packaging the libraries. The other advantage of using the system package manager is that dependencies (shared libraries) that are common can be shared between many applications, saving space.

[1] https://conan.io/

I do however always recommend using a package manager: vcpkg or Conan to install and integrate third party libraries (together with CMake). This normally solves all the typical problems with dependencies.

There's a few, look into Conan or vcpkg (the latter is my personal recommendation).

You could check Conan and Vcpkg, they can be used to provide your dependencies for all three major platform (but I think only as pre-build binaries). Or you could embed the installers of your dependencies in your own.

There are "package managers" for C++ which can download / build / install the packages you want to use in your project, you only need to give a list of the package names to it. If you want something like that you should check out Conan and vcpkg.

Luckily, it's 2023, and not 2003 anymore and there are better ways: package managers. Package managers like Conan and vcpkg use ready made recipes for downloading and building a lot of open-source software libraries, and they are made to work out of the box and also build dependencies and dependencies of dependencies. They keep track of all the dependencies a project needs and ensure that they all work together. CMake works really well with these package managers, so stick to that - it is the future.

Or the absolute Gold standard in 2023: use a package manager: Conan or vcpkg.

5.4.5 can be compromised

https://github.com/microsoft/vcpkg/issues/37197

vcpkg may expire assets after 1.5 years, so achieve long-term reproducibility you will need to cache your dependencies.... Somewhere. Not sure what the expected solution is.

https://github.com/microsoft/vcpkg/pull/30546#issuecomment-1...

There were various approaches recommended depending on our language and ecosystem. My classmates who developed using Node.js were recommended npm, and PyPI or poetry for Python. Since my program is written in C++, I was recommended to look into one of vcpkg or conan, but I ultimately did not use either package manager.

Which dependencies are not in vcpkg? We can ask them to add it. It’s pretty easy just open an issue there https://github.com/microsoft/vcpkg/issues .

CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message): Command failed: /usr/bin/cmake --build . --config Debug --target install -- -v -j25 Working Directory: /opt/vcpkg/buildtrees/hyperscan/x64-linux-dbg See logs for more information: /opt/vcpkg/buildtrees/hyperscan/install-x64-linux-dbg-out.log Call Stack (most recent call first): installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process) installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build) ports/hyperscan/portfile.cmake:22 (vcpkg_cmake_install) scripts/ports.cmake:147 (include) error: building hyperscan:x64-linux failed with: BUILD_FAILED Please ensure you're using the latest port files with `git pull` and `vcpkg update`. Then check for known issues at: https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+hyperscan You can submit a new issue at: https://github.com/microsoft/vcpkg/issues/new?title=[hyperscan]+Build+error&body=Copy+issue+body+from+%2Fopt%2Fvcpkg%2Finstalled%2Fvcpkg%2Fissue_body.md You can also sumbit an issue by running (GitHub cli must be installed): gh issue create -R microsoft/vcpkg --title "[hyperscan] Build failure" --body-file /opt/vcpkg/installed/vcpkg/issue_body.md

The hyperscan update to vcpkg seems to have happened from 5.4.0 to 5.4.2 in this commit on Apr 20.

Dear Fictrac team, I am hoping to install Fictrac in our windows 11 x64 laptop (Visual Studio 2019, cMake 3.26.4). I followed the installation guideline on github page fictrac and used the latest vcpkg

unless you want to use clang-cl since it renames the output to make it work for MSVC which in return breaks FindBoost in cmake and requieres https://github.com/microsoft/vcpkg/pull/27694 to fix it. I have touched enough of vcpkg build scripts to know what works and what doesn't and the b2 build is one of the corners I strongly dislike.

And then there's also Qt which has plugins. vcpkg Qt5 is nice enough to copy the plugins for you, but not with Qt6. The official answer seems to be "use windeployqt". So I do, and it copies plugins fine. But sqlite doesn't work, despite the plugin sqldrivers/qsqlite.dll being in the right location. Turns out that neither vcpkg or windeployqt copy sqlite3.dll. I switched to static libraries after that, it's a lot slower to link, clang doesn't work for some reason (but clang-cl does) but at least I don't have to worry about DLLs.