Vcpkg
Samuel Henderson

The Visual C++ has a blog post about their latest and greatest tool : Vcpkg. A package manager for Visual C++ akin yum/dnf/apt-get/Homebrew

Read all about it here:
https://blogs.msdn.microsoft.com/vcblog/2016/09/19/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/

I noticed that the 6th package in their list is Good ol' Allegro5.

What are people's thoughts on this? I think it's an interesting idea. The only other C++ package manager I've seen is https://conan.io/, but I've never tried it.

LennyLen

So this means they're dumping NuGet then?

Samuel Henderson
LennyLen said:

So this means they're dumping NuGet then

I think NuGet is specific to .NET libraries. I could be wrong. I've used it for some C# projects (Apache log4net, Json.NET) and it's pretty seemless. Although, adding the references manually wasn't that hard either.

So it could be safe to say this is probably similar to NuGet, except for un-managed C++ code.

LennyLen

I think NuGet is specific to .NET libraries.

I used it to get Allegro 5

jmasterx

I think NuGet is specific to .NET libraries. I could be wrong. I've used it for some C# projects (Apache log4net, Json.NET) and it's pretty seemless. Although, adding the references manually wasn't that hard either.

So it could be safe to say this is probably similar to NuGet, except for un-managed C++ code.

{"name":"611315","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/e\/6e639a081d1e95ef9307e3062827270c.jpg","w":1629,"h":650,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/e\/6e639a081d1e95ef9307e3062827270c"}611315

MiquelFire

vcpkg has something in their FAQ about why you would use it instead of nuget.

Basically, vcpkg allows you to compile the library on your side while nuget relies on a pre-made binary.

Samuel Henderson

Ah I see. Well, according to FAQ:

Quote:

Why not NuGet?
NuGet is a package manager for .NET libraries with a strong dependency on MSBuild. It does not meet the specific needs of Native C++ customers in at least three ways.

Compilation Flavors. With so many possible combinations of compilation options, the task of providing a truly complete set of options is intrinsicly impossible. Furthermore, the download size for reasonably complete binary packages becomes enormous. This makes it a requirement to split the results into multiple packages, but then searching becomes very difficult.

Binary vs Source. Very closely tied to the first point, NuGet is designed from the ground up to provide relatively small, prebuilt binaries. Due to the nature of native code, developers need to have access to the source code to ensure ABI compatibility, performance, integrity, and debuggability.

Per-dll vs Per-application. NuGet is highly project centric. This works well in managed languages with naturally stable ABIs, because base libraries can continue to evolve without breaking those higher up. However, in native languages where the ABI is much more fragile, the only robust strategy is to explicitly build each library against the exact dependencies that will be included in the final application. This is difficult to ensure in NuGet and leads to a highly disconnected and independently versioned ecosystem.

They also have a similar section about why Vcpkg should be used over Conan.io and chocolatey.

Neil Roy

Basically, vcpkg allows you to compile the library on your side while nuget relies on a pre-made binary.

Makes me like nuget better. Compiling it yourself leads to all sorts of problems. Too many I see on here used nuget and didn't have a problem with it.

SiegeLord

The size issue they refer to is definitely a real concern for the Allegro nuget package. I had to drop support for MSVC 2013, and only provide 3 compilation variants for MSVC 2015 and 2017 and then 32 and 64 bit. That's basically 12x the size of the full Allegro binaries, totaling about 50MiB. One concern is that we actually vendor the dependencies, so we'd have to figure out how to build those without things getting crazy, but it can probably be done.

Still, overall this seems like a nice idea, it'd be great to have this as another option for Allegro.

EDIT: Wait a second, Allegro's already there! It's likely not as nice as the Nuget package we make, but still kind of cool!

bamccaig

On a side note, can we all agree that the name is shitty? :P It's obscure. It makes sense, but it needlessly is limiting in platform which means it will also reduce adoption. There's no need for a platform and language specific packaging system. A much better venture would be a cross-platform packaging system for C++ (and other native, or ANY) code. 20 years ago a "vcpkg" project would have probably been huge. Today, I don't think it will be. They're too late, and too focused.

Neil Roy
bamccaig said:

On a side note, can we all agree that the name is shitty?

Yup! Agreed. We're not limited to an 8.3 filename anymore. ;)

Samuel Henderson

I guess the name follows the pattern Microsoft seems to have established for their C++ products ...
MSVC
MSVC Runtime
VCLinux
etc
VCpkg

bamccaig said:

It makes sense, but it needlessly is limiting in platform which means it will also reduce adoption. There's no need for a platform and language specific packaging system. A much better venture would be a cross-platform packaging system for C++ (and other native, or ANY) code.

Agreed. I was hoping this would make developing on Windows as easy as it is on Linux. Something akin to the linux package managers like
`$ vcpkg install allegro5 allegro5-devel`

Which would place the libraries and library header files into some sort of windows equivalent of /usr/lib and /usr/include .. Maybe something like C:\Users<username>\Vcpkg\lib, C:\Users<username>\Vcpkg\include

I think that would still be somewhat useful. You could set Visual Studio (or whatever compiler you are using in Windows) to look in those directories for includes and linking.

The team does seem open to having the tool be cross platform ... but again, on Linux you have apt-get, yum/dnf, etc etc, macOS has Homebrew ...

It may be too late to make a big difference ... but I don't see a problem with another way of getting libraries :)

bamccaig

On another note, they really screwed up NuGet because there's basically no authority managing the main repo. Just about anybody can put together a package and get it added to the repository. The result is that there's sometimes several versions from several people and you have to be careful to get it from a trusted source. Also several of the packages are poorly made and there's almost zero consistency between them. The name of the package is also unpredictable as a result. Sometimes the package that sounds like it would be official is not. The whole point of a package management system to make it easy. NuGet doesn't really solve problems very well. It's original integration with Visual Studio was also pretty poor, which lead to a lot of breakage and headaches. I think they've nearly got it working in the latest version, but it could also be that we've just managed to figure out how to configure it so it works.. Things that I expect the vcpkg team to also fuck up due to the Microsoft ecosystem/culture. :P

Samuel Henderson
bamccaig said:

It's original integration with Visual Studio was also pretty poor, which lead to a lot of breakage and headaches. I think they've nearly got it working in the latest version, but it could also be that we've just managed to figure out how to configure it so it works..

How so? I've been using NuGet since Visual Studio 2013 and have never had a single problem with it, granted I typically only use two or three very prominent packages.

bamccaig

It used to be very flaky to restore packages on a separate computer. I.e., you setup a project with many NuGet dependencies, commit the code and package config, and push it to a shared repo. Another developer pulls and tries to build. It used to be too stupid to restore the packages automatically, and the user-controlled tools to restore them were very flaky. We had several problems with it where we were. Each of us got blocked by it for several hours on several occasions. I'm not sure if it's gotten better, or if we've just gotten better at working around it, but (knock on wood) I haven't had an issue since upgrading to 2017.

Samuel Henderson

That's very weird. It's always pulled the packages in after pulling code out of source control, even on clean build machines (using both svn and bitbucket/git). It's always just worked for us since Visual Studio 2013.

The biggest problem I've personally experienced with NuGet is that it still doesn't use the system proxy, but that's like a 5 minute fix.

Thread #617297. Printed from Allegro.cc