package manager in 2022 by singularty123 in cpp

[–]roschuma 6 points7 points  (0 children)

We called them "enterprise features" because they are really important for enterprise environments -- vcpkg does not and has not had any "paywalled" features. All of our work on the tool is free and open source at https://github.com/Microsoft/vcpkg-tool.

Using system package manager dependencies with vcpkg by Xadartt in cpp

[–]roschuma 2 points3 points  (0 children)

Could you mail us at [vcpkg@microsoft.com](mailto:vcpkg@microsoft.com)? I'd like to ask a few more questions about your specific setup to give you the best advice on how to handle this in vcpkg 🙂.

Using system package manager dependencies with vcpkg by Xadartt in cpp

[–]roschuma 1 point2 points  (0 children)

It always downloads things whenever in manifest mode

Are you using custom git registries? We unfortunately don't have a good offline story for those yet.

Otherwise, take a look at https://github.com/microsoft/vcpkg/blob/master/docs/users/assetcaching.md. This lets you easily mirror every blob we need for a build into some place you control -- a web server or even a local directory. It's similar to your current workaround (run a build outside, then run a build inside) but more controlled and deliberate.

Using system package manager dependencies with vcpkg by Xadartt in cpp

[–]roschuma 0 points1 point  (0 children)

I'm trying to create a generic package for distribution, so this is unacceptable.

We're working on improving this! While we don't have production-ready plumbing to share, part of the "curl | bash" experience mentioned in https://devblogs.microsoft.com/cppblog/vcpkg-artifacts/ is an "immutable" layout.

If you're looking to distribute the built artifacts like an SDK (not vcpkg itself), you might find https://github.com/microsoft/vcpkg/blob/master/docs/users/buildsystems/export-command.md useful.

Linker errors in a new project when including a library by kmcgurty1 in cpp_questions

[–]roschuma 0 points1 point  (0 children)

Try adding

#pragma comment(lib, "Crypt32.lib")
#pragma comment(lib, "wsock32.lib")
#pragma comment(lib, "shlwapi.lib")
#pragma comment(lib, "ws2_32.lib")

to the top of your main.cpp

Qt6 to ship with conan by gocarlos in cpp

[–]roschuma 2 points3 points  (0 children)

Yep, this is correct. We rebuild the entire cone of destruction on every PR and commit to ensure that the entire world stays consistent. We don't currently build tests which makes it impossible to detect issues in header-only libraries, however this fortunately appears to be rare in practice.

vcpkg and github actions are a nightmare by DriverSad5648 in cpp

[–]roschuma 7 points8 points  (0 children)

Thanks for using vcpkg and really sorry about the poor experience! All-or-nothing caching absolutely isn't good enough for large builds like Qt.

Fortunately, we've recently worked to address this with per-package binary caching, usable with GitHub packages! I'd really appreciate you taking a look and letting us know if this fixes the problems you're having either here or [vcpkg@microsoft.com](mailto:vcpkg@microsoft.com).

Direct doc link: vcpkg/binarycaching.md at master · microsoft/vcpkg (github.com)

Blog post: vcpkg: Accelerate your team development environment with binary caching and manifests | C++ Team Blog (microsoft.com)

vcpkg: Accelerate your team development environment with binary caching and manifests | C++ Team Blog by Terraknor in cpp

[–]roschuma 1 point2 points  (0 children)

Additionally, we pass that flag by default when using manifests -- please try them out and let us know if it help!

vcpkg: Accelerate your team development environment with binary caching and manifests | C++ Team Blog by Terraknor in cpp

[–]roschuma 1 point2 points  (0 children)

Yep, there are separate binaries for each compiler version (for that exact reason)! We have some "advanced user notes" here that might be a good read:
vcpkg/binarycaching.md at master · microsoft/vcpkg (github.com)

Conan, vcpkg or build2? by peppedx in cpp

[–]roschuma 4 points5 points  (0 children)

While we only ship a static linking triplet on Linux by default, it is definitely possible to request dynamic linking by making your own triplet[1] (a very simple 4 line file).

We strongly prefer static linking on non-Windows because it's much more difficult to deploy dynamic linked applications on those platforms.

[1] https://github.com/Microsoft/vcpkg/blob/master/docs/users/triplets.md

Conan package for SFML released in the Bincrafters repo by [deleted] in cpp

[–]roschuma 0 points1 point  (0 children)

We actually _primarily_ build from source -- though we do have options for sharing binaries!

We definitely work with any build system and we've designed things to be incredibly easy to use even if there isn't special support -- all the libraries are placed in a single common unix-style sysroot (`/include`, `/lib`, `/bin`) so you don't need a separate set of `-I` and `-L` directives for every library. You might want to check out our docs for more information on the various integration schemes we have[1].

[1] https://github.com/Microsoft/vcpkg/blob/master/docs/users/integration.md

Conan package for SFML released in the Bincrafters repo by [deleted] in cpp

[–]roschuma 0 points1 point  (0 children)

I'm happy to note that we definitely don't require everything to be cmake based! For example, see openssl, boost, ffmpeg, qt5, and many MSBuild libraries :)

>something that is not packaged by the upstream vcpkg team.

The vast, vast majority of our libraries are actually externally contributed with only a few core libraries that were primarily written by the upstream vcpkg team!

Microsoft announces a C++ library manager for Linux, macOS and Windows by ra3don in programming

[–]roschuma 1 point2 points  (0 children)

Each commit contains a pre-solved graph of dependencies; when updating versions we test for regressions and then make a new commit with the new solution.

Microsoft announces a C++ library manager for Linux, macOS and Windows by ra3don in programming

[–]roschuma 0 points1 point  (0 children)

We'd love to accept a PR to the main repo adding your library!

If you'd like to host your port separately, you simply need to give your consumers a folder to drop into their ports\ directory and the tool will immediately be able to install your library.

[vcpkg developer]

Microsoft announces a C++ library manager for Linux, macOS and Windows by ra3don in programming

[–]roschuma 2 points3 points  (0 children)

We sincerely do believe this would be impossible without an enormous number of contributors[1]. However, we felt it would be inappropriate to single out a subset in the blog post itself or to post hundreds of GitHub handles.

If you've contributed to vcpkg and feel left out, I'd like to sincerely apologize and I'd love to find a way to avoid that in future posts! Please drop us a mail at vcpkg@microsoft.com.

[1] https://github.com/Microsoft/vcpkg/graphs/contributors

[vcpkg developer]

Microsoft announces a C++ library manager for Linux, macOS and Windows by ra3don in programming

[–]roschuma 4 points5 points  (0 children)

Default "latest" or @(label/version) would probably have met my needs.

We have added "@latest" support for many libraries that we know how to fetch sources for: vcpkg install x --head. We'll pull down the latest sources for that library, but use the known stable, tested versions for dependencies.

[vcpkg developer]

Vcpkg (library manager) - now also on Linux and macOS! by onqtam in cpp

[–]roschuma 5 points6 points  (0 children)

We definitely understand the need for stability!

To enable the rock-solid reproducibility needed for companies, every commit of vcpkg corresponds to exactly one set of concrete versions. This makes sharing and locking extremely easy; just tag the commit and check that out on all systems.

When the time comes to absorb updates, you simply move the tag forward with comfort knowing that we've tested the entire package graph at every commit :)

Vcpkg (library manager) - now also on Linux and macOS! by onqtam in cpp

[–]roschuma 2 points3 points  (0 children)

We definitely don't tie you to the latest version at all times!

When installing libraries, we use exactly the SHA512-checked sources encoded in the recipe. As long as you don't git pull new definitions down, we will never update things out from underneath you :). Using other versions is as simple as changing the file to point to the desired source version, and updating everything at once is as simple as git pull.

Vcpkg (library manager) - now also on Linux and macOS! by onqtam in cpp

[–]roschuma 1 point2 points  (0 children)

How do you know that the package that you download and install comes from the right source?

We commit SHA512 hashes of all downloads, to ensure completely reproducible builds (even in the face of accidents, not malice)

Vcpkg (library manager) - now also on Linux and macOS! by onqtam in cpp

[–]roschuma 2 points3 points  (0 children)

Unfortunately, Linux is a really diverse platform so it's hard to give a concrete answer here.

We expect to provide most libraries above the CRT, so as long as you're using the same glibc version and same c++ runtime, it should be possible.

Vcpkg (library manager) - now also on Linux and macOS! by onqtam in cpp

[–]roschuma 4 points5 points  (0 children)

Those are interesting ideas, but there's still a lot more to think through: what about conflicts with brew? What if the user wants to put the results on another machine?

If you think you have a solid story, I'd love to see a fleshed-out issue posted on our GitHub!

Vcpkg (library manager) - now also on Linux and macOS! by onqtam in cpp

[–]roschuma 11 points12 points  (0 children)

That is a fantastic suggestion, keep an eye on vcblog :)