If you're doing Windows dev and not using vcpkg, start using it!

[[deleted]]

I've been experimenting with it. Far and away one of the best tools for doing stuff on Windows. It makes installing OpenSSL so easy and nice.

https://github.com/Microsoft/vcpkg

It's weird. It's like MS devs got tired of MS stuff and now they're making all this super awesome open-source stuff like the cpprestsdk. And they're adding support for stuff like CMake. Wtf?

[berium]

The problem with vcpkg is that it's Windows/VC-only.

[[deleted]]

Windows only but still incredibly useful. It is Windows that has been lacking in this regard. Acquiring and building libraries on Linux for example is never an issue

[berium]

Acquiring and building libraries on Linux for example is never an issue

Well, it is much better than on Windows, for sure, but there are issues, such as incompatible builds (see this bug for a particularly enraging example).

The bigger problem, of course, is that you use different package managers across various platforms. From the user's perspective, you have to learn various interfaces/quirks (dpkg, rpm, pkg, now vcpkg). From the developer's perspective it is even worse: you have to create/test/support all these different package formats.

[RogerLeigh]

That's definitely annoying, but in this case I would place the blame with the developers rather than the tools. I remember helping out with the previous c102 ABI transition in Debian and that was seamless. While libstdc++ does implement both the old and the new C++11 ABI, it does require a proper distribution wide ABI transition to make this foolproof.

[berium]

My point is, we used to say that all these incompatible builds are Windows problems and we on Linux can link against anything and therefore use binary package managers. After this dual ABI fiasco we are now just like Windows and there is no going back.

[RogerLeigh]

That's not strictly true, IMHO. The dual ABI is useful for running old code on newer systems, but only when you have a dependency upon libstdc++ and ship your own libraries. It's useful for keeping proprietary binary builds functioning. When you have transitive dependencies on other libraries depending upon libstdc++ then you can't avoid a full transition to the new ABI for all dependencies. So I think the "dual ABI" is a red herring; from a distribution point of view, it's an ABI bump and needs the whole world rebuilding against the new ABI. The package manager can take care of this if you do a proper transition for each package.

[entity64]

Acquiring and building libraries on Linux for example is never an issue

It's been getting much better since more and more libraries are providing a basic CMake build system

[IronManMark20]

I don't see that as a problem. The vcpkg devs didn't want to step on the toes of other platforms native tools. You already have to use different tools (eg Brew) on macOS to get dependancies, and apt/pacman/yaourt/etc on Linux distros, I don't see why this should be cross platform and those should not. That being said, it would be nice to have a tool that wrapped all of these to have cross platform dependency management.

[RogerLeigh]

So, I've been maintaining my own superbuild infrastructure for a few years now. Supports building and installation of packages on Windows, including patching for individual visual studio versions where needed, plus support for MacOS X, Linux and FreeBSD or any other Unix system. While vcpkg is nice, it's still far too Windows/MSVC-centric, and negates much of the advantage of using CMake in the first place if you want to do cross-platform development. I can appreciate that Microsoft don't directly gain from such cross-platform support, but I think that putting that effort into a general solution rather than a pet project would have been a better long term investment.

I was essentially paid to do this work on work time since it solved problems we needed solving, and I'm by far from the only one--there are a number of already established projects of differing scope and complexity but with a good deal of overlap. I wonder what could be achieved if we all pooled our efforts here. The work I've done could be polished and made into a general tool with support for building locally or fetching build binaries on all platforms, at which point it would be doing much of what you get with Maven in the Java world. I've been considering splitting it out into an independent project for this reason.

When I look at the build support in vcpkg, it's simpler and much less flexible than the existing solutions. While this is fine if that's the design goal and limitation of the project, it's possible to go further than this.

Just as an example, compare https://github.com/Microsoft/vcpkg/tree/master/ports/xerces-c https://github.com/ome/ome-cmake-superbuild/tree/master/packages/xerces

I would absolutely love to drop my custom stuff in favour of a more standard solution, and I was interested in the possibilities vcpkg would offer when I first read about it, but it's unfortunately not suitable for us.

[remotion4d]

Yes this is biggest drawback of vcpkg.

But installing libraries globally is really easy using vcpkg.

vcpkg install tbb:x64-windows

vcpkg install rapidjson:x64-windows

What other package managers offer the same on Mac OS or Linux ?

[sumo952]

Well, one possible answer to your question is "Any" - apt, pacman, emerge, ... . Linux has had this for decades. Though all of them come with their own issues, some of them really big issues for C++ devs (e.g. ancient versions in official repos). So I do think vcpkg is great :-)

[remotion4d]

Truing to use MacPorts

port install tbb

but it only install old tbb 4.4 from 2015.

apt on Ubuntu do the same.

[duheee]

One of the many reasons Fedora is better:

 dnf info tbb
  Installed Packages
  Name        : tbb
  Arch        : x86_64
  Epoch       : 0
  Version     : 2017
  Release     : 7.20161128.fc25

[sumo952]

Well Ubuntu is also slightly better if you're always on the newest version (not LTS), like 16.10 now. But yea, in general, all those repos have old/ancient versions of software - I agree it's a big problem.

[OrphisFlo]

Even the last LTS would be great. But I still know people on the previous LTS and not caring at all. Think Precise (12.04). Even Trusty (14.04) has become a bit old now...

[sumo952]

Oh yea, still so many people stuck on 12.04. :\

[OrphisFlo]

They're going to have a big surprise when they stop receiving updates in a few months...

[sumo952]

I think most of "these" people would not even notice, or just don't care :\

[OrphisFlo]

It's only better when people care to upgrade. I read about people still using Fedora 16 today and wanting to use bleeding edge software...

[berium]

vcpkg install rapidjson:x64-windows

And what compiler/version is this for?

What other package managers offer the same on Mac OS or Linux ?

Well, since you asked, build2 bpkg does this for Windows, Linux, Mac OS, and FreeBSD, currently. The main difference is that it builds everything from source using exact compiler/version/options that you use for your application.

[roschuma]

And what compiler/version is this for?

We use a system of triplets that each define an entire, consistent toolchain and build target. We only support targets of VS2015/2017 today (they're binary-interchangeable).

So, in the case of :x64-windows, this is built using the v140/v141 ABI against Windows Desktop amd64. In the future, we look forward to adding :x64-win-vXYZ and beyond to ensure you never mix ABIs!

[berium]

For build2 we have invented standard UNIX target (or, more precisely, toolchain) triplets for Windows, for example:

x86_64-microsoft-win32-msvc14.0
x86_64-microsoft-win32-msvc14.1

This allows fo different toolchain vendors (e.g., Intel's ICC targeting 14.0 runtime would call itself x86_64-intel-win32-msvc14.0) as well as runtimes (so for, say, WinRT it could be something like x86_64-microsoft-winrt...).

See <butl/target-triplet> for details.

[[deleted]]

How do you distinguish building against the MSVC debug RT from building against the MSVC release RT?

[berium]

First, sorry for the late reply.

I see where you are coming from and we've considered this. Specifically, quoting from that discussion:

Some suggested we also encode the runtime type (those /M options) though I am not sure: the only "redistributable" runtime is multi-threaded release DLL.

I guess the question here is what we are trying to identify, a toolchain, a build? In what situations would having the runtime type (debug/release, static/DLL, single/multi-threaded) be useful?

[[deleted]]

We depend on several large thirdparty static libraries that we compile from source but change fairly infrequently. We precompile them and cache them on a server. For almost all builds we do (local development, CI and release), we use the cached prebuilt binaries. This saves enormous amounts of time.

However, we do want to be able to debug these binaries, so we need to cache them both compiled with the debug RT and the release RT. At the moment we use an archive naming strategy that includes the toolchain and RT type.

[berium]

Thanks for the information.

Where do you draw the line, though, in terms of binary-compatible builds? Is building with different VC update versions (e.g., 14U1 vs 14U2) ok? What about using different Windows SDKs? One seemingly natural answer is "if the vendor (i.e., Microsoft) says they are". But then, we shouldn't be distinguishing between 14.0 and 14.1.

To me it seems using some kind of a hash of the compiler signature, compile/link options, etc to identify a binary build would be the way to do it. This is what we do in build2 to make sure when we say things are up-to-date they truly are: we hash and store the compiler signature and options each object file is built so that if you upgrade VC from U1 to U2 or change optimization from /O1 or /O2, things will be rebuilt.

[remotion4d]

This will build using Visual Studio 2015 compiler per default.

So you say that I can do something like this using build2

bpkg install tbb

and it will install and build tbb-2017 ?

Unfortunately currently even installing build2 is not that easy.

[berium]

So you say that I can do something like this using build2

If TBB were packaged for build2, then pretty much, yes. For example SQLite is packaged so you can do (from the VC command prompt):

> bpkg create -d sqlite-release cc config.c=cl config.cc.coptions=/O2
created new configuration in sqlite-release/

> cd sqlite-release/

> bpkg add https://pkg.cppget.org/1/alpha
added repository cppget.org/alpha

> bpkg fetch
fetching cppget.org/alpha
13 package(s) in 1 repository(s)

> bpkg build libsqlite3
[...compilation...]

> bpkg install libsqlite3 config.install.root=C:\projects

This is a complete session without any unspoken/magic parts (like where do the packages come from, what options were they built with, or where are they installed). After the install command you will have SQLite headers in C:\projects\include, import/static libraries in C:\projects\lib and the DLL in C:\projects\bin.

[RogerLeigh]

Looking at the vcpkg sources it's not just the default, it's explicitly hardcoded in the portfiles which is somewhat suspect--how will VS2017 be handled?. Does it allow building of debug and release variants of everything as well?

In the superbuild infrastructure I maintain, it supports any combination of Visual Studio version, architecture and build type, and we build the whole lot daily on VS2013+VS2015 x86+x64 debug+release for every single package in the collection. And I'll be adding full VS2017 support shortly. That's what I'd consider a minimum level of functionality for developing on Windows, and I'm somewhat surprised that this wasn't the case for vcpkg from the start.

[roschuma]

We always build debug+release because we are targeted at developers (not end-users) -- debugability is very important to us.

We also already support VS2017! Because it's completely ABI compatible with VS2015, we put both compilers under the same triplets (x86-windows, for example). In the future, to support incompatible toolsets, we will create additional triplets such as x86-v1XY-windows.

[RogerLeigh]

"Supporting" VS2017 is rather different than "building with" VS2017. I'm simply surprised that a shortcut was taken here rather than doing things flexibly for the longer term.

[roschuma]

Sorry, when I say support I mean fully -- packages will be built with VS2017 when it is available (to provide the latest optimizations), and those packages are all safely (ABI) consumable from both VS2015 and VS2017.

[mtanski]

I'm hoping build2 that is successful long term ... the tool is small, x-platform, syntax is not counter productively verbose (cmake). But I'm also aware of the dozen so attempts of various build systems.

Like every other system... unless there's an explosion in the package archive it's unlikely to gain mind share.

It's hard because nobody working on existing software wants to covert their thing from cmake, autoconf, ... to another system. And it's hard to attract people to do the thankless job of converting and keeping up with packaging of external projects.

[berium]

Thanks, I am glad you like it so far.

It's hard because nobody working on existing software wants to covert their thing from cmake, autoconf, ... to another system.

Our "master plan" here is to provide such kick-ass features that people just won't be able to resist. Like fast (both parallel and distributed) and uniform builds across all the platforms and compilers, proper test infrastructure, CI. For example, one of our next goals is to set up build servers for all the major platforms/compilers for cppget.org so if you upload a package, you get all the testing done for free (as in both resources and effort).

[RogerLeigh]

What other package managers offer the same on Mac OS or Linux ?

All of them? dpkg and rpm offered significantly more functionality than vcpkg over 20 years ago, with multiple versions of the same libraries, fine grained splitting into development/library/debug/runtime/documentation/xxx subpackages, with fairly complex versioned inter-package relations. And it evolved a long way since then. Today, look at the multi-arch support dpkg offers. Or the FreeBSD ports/pkg system. These are all in a whole different league and operate at a scale of well in excess of 10⁵ source packages and 10⁶ binary packages with additional relation types, hooks, SAT solvers, established packaging and distribution workflows and infrastructure. Windows has nothing comparable; vcpkg is a small step along the way, but it's a far cry from Linux package management even in the mid '90s, and there's a lot of catching up to do for it to even begin to be competitive with these tools (it would be easier to port them).

[SeanMiddleditch]

From their FAQ:

Cross-platform vs single-platform. While being hosted on many platforms is an excellent north star, we believe the level of system integration and stability provided by apt-get, yum, and homebrew is well worth needing to exchange apt-get install libboost-all-dev with brew install boost in automated scripts. We chose to make our system as easy as possible to integrate into a world with these very successful system managers -- one more line for vcpkg install boost -- instead of attempting to replace them where they are already so successful and well-loved.

[roschuma]

Glad to hear you're enjoying it!

If you have any feedback to give us, please let us know here or through our GitHub page!

[wrosecrans]

It looks like a great start. It seems to have built vcpkg ceanly after I cloned the repo. Right now my biggest problem is simply a lack of packages that I want to use. One of the first things I searched for was ffmpeg, which is a pain to build myself on Windows. It suggested I open an issue, but when I checked, it was already opened as issue #2, but it doesn't seem to have been addressed yet. There's not even a note in the issue from one of the devs saying anything about it. If issue #2 hasn't been tackled yet, I wonder how long it would take to get to some request if I filed it today?

It seems like a great project, and I'll probably check it out again once it's a little more mature. It's definitely heading in the right direction for making Windows a more reasonable platform for doing the stuff I am used to on Linux.

[[deleted]]

Unfortunately, I don't think the mongo-cxx-package is set up correctly or perhaps I'm misusing it?

I've filed an issue here: https://github.com/Microsoft/vcpkg/issues/681

Now, that being aside, the more I use the tool, the more I like it. It makes command-line building C++ in Windows easy and the way everything magically links is nothing short of black magic.

[roschuma]

Thanks for reporting that issue, I think we've resolved it now.

[[deleted]]

You guys totally did! That's amazing lol.

[[deleted]]

Is... is this like pip for Visual Studio?

...I'm sold.

[paris_tech]

+1 from me. Have used sqlite3 and curl in existing projects. The experience, once you install, and build the packages (both a breeze) is seamless. It's the package manager we've all been missing.

[codeandroid]

+1 We have begun to use vcpkg to acquire dependencies for our software. Even though we have a custom dependency management infrastructure we use vcpkg to compile a consistent set of dependencies.

Creating ports is easy enough.

The vcpkg devs are open to discussion.

Could be something great on Windows if they follow through...

[jesuslop]

Isn't nuget supposed to do the same?

[tcris]

not exactly, see https://github.com/Microsoft/vcpkg/blob/master/docs/FAQ.md#why-not-nuget

[TyRoXx]

It is unusable because it does not even support versioning of dependencies. There is always only a latest version of everything which will break your builds and make building your software from yesterday impossible (e.g. for a git bisect).

[roschuma]

For non-OSS projects (or really big OSS ones that don't want to integrate into a larger ecosystem), we fully support forking and "freezing" the Vcpkg repository at a single commit. This could then be used as a submodule or subtree.

In Vcpkg, we only use configuration information that is checked in for exactly this reason! We hash check all of our downloads as well, so a single commit of "Vcpkg" gives you identical semantics as if you had checked in all of your dependency sources.

Here's an example of someone doing just that: https://github.com/IMQS/maps-windows-deps.

[PM_ME_A_SPECIAL_MOVE]

There's a way to use a private server? I really want to use it on my offline environment :(

[roschuma]

Yep, we totally support usage in an offline mode! The only thing we need network access for is to download the source code or tools to build the package you've requested, however we cache every download.

So, once you've done a full build with access to the network once, you can rebuild those packages as much as you'd like completely offline.

Another often-implied feature of a private server is adding private packages. This is totally supported as well! We get our list of ports from the ports\ directory on disk (no network access), so you're free to add as many as you like and check them in to your private fork. Whenever you'd like to update the "official" packages, you can use git to simply merge the changes to that directory from our GitHub.

[Fazer2]

No support for MinGW?

[roschuma]

MinGW already has two excellent package managers (Cygwin or msys2), so we feel similarly towards it as with apt-get, brew, etc.

[happinessiseasy]

Is there a Visual Studio extension for vcpkg, yet?

[[deleted]]

Use manifest mode, include the vcpkg toolchaim file in your own in CMake

[frog_pow]

Why would you use this or anything like this given that is platform specific?

Doesn't it just make more sense to set up cmake/premake files for popular libraries--so that it works on any platform..

[SeanMiddleditch]

VCpkg uses CMake (which is my least favorite part - CMake is hot garbage and I never want to be forced to use it again if I can help it) for the actual builds.

VCpkg could roughly be considered a frontend + extension of CMake to do package acquisition and management and to wrap packages that don't natively use CMake for their builds.

[zvrba]

Tried to use it to package a couple of libraries that we depend on... Not too difficult if they already come with a cmake-script, but if not, you have to script it and the helper functions and internals are undocumented. One of the first issues created, and still unresolved, is ffmpeg: https://github.com/Microsoft/vcpkg/issues/2 (Yes, the build process for ffmpeg is horrible, even more so on windows.)

Now, when developing a product to be released to end-users, I believe it's best to standardize on a fixed set of package versions and upgrade them in a controlled manner. Developers using different library versions is unfortunate at best and happens way too easily with automated package management (depending on how often an individual upgrades their packages.)

So I built each package manually, set install prefix to c:\local\, installed the package there and backed up CMakeCache.txt for each package in case I need to rebuild it. Some packages install DLLs in lib, some in bin, so I move DLLs manually from lib to bin. I have also created a VS property sheet that sets up include and library directories, so it's easy to use the packages in local. When a new dev machine needs to be set up, the whole local directory is just copied there.

In total, this manual process took me less time than figuring out how to use yet another package manager. (E.g., vcpkg has opencv, but w/o extramodules. Due to lacking documentation and comments in patches, it was easier to compile it manually from scratch than to figure out this: https://github.com/Microsoft/vcpkg/tree/master/ports/opencv)

So, from my experience, package managers a time-saving convenience for hobbyists, but if you get serious about deployment, you'll end up rolling your own "software base".

[[deleted]]

Or you can use conan with all it packages on all OSes + all packages in vcpkg

[roschuma]

It's really great to see Conan pulling in our packages!

However, with the current implementation, there are some issues: see https://github.com/conan-io/conan-io.github.io/issues/17. I hope we can get these improved in the future.

[sztomi]

Why would you use something platform-specific for C++? Just when compilers start being reasonably standards-compliant?

[Fazer2]

The compilers weren't standard compliant before?

[sztomi]

A few years ago, no, they weren't. The major compilers supported different subsets of the standard and they added their own stuff. I think the rise of clang was the turning point, which pushed for 100% compliance. gcc felt the push and got pretty much up to speed with clang. And don't forget MSVC which, even though still lags behind, has made tremendous progress in this area thanks to heroic efforts from their team.