Hacker News new | comments | ask | show | jobs | submit login
Announcing a single C++ library manager for Linux, macOS and Windows: Vcpkg (microsoft.com)
64 points by ingve 10 months ago | hide | past | web | favorite | 30 comments



Digging around the announcement a bit, I'm having a hard time seeing why I might prefer this over Conan[1], and I'm not seeing anything about how I can stand up my own private repository for vcpkg, which is what I am about to do with Conan. Can anyone sound off (or link a page where someone has done so) on what might tip someone toward this over Conan or vice versa?

[1](https://www.conan.io/)


vcpkg has an FAQ[1] regarding this, if someone could find one from the other perspective I think that would be helpful.

Personally, I prefer their integration with CMake, letting me `find_package(spdlog 0.16 REQUIRED)` allowing others to point to their own version with `-Dspdlog_DIR=...`.

[1] https://github.com/Microsoft/vcpkg/blob/master/docs/about/fa...


Thanks. It looks like at least the third bullet has been reconsidered, based on this announcement.

But I think the front matter on that section gives (at least for what I'm after) a pretty good start on an answer to my question. They aim to version all libraries together as a platform (like, say, homebrew or yum+rpm). Where Conan aims to behave a little more like what I'd term "pypi for C++". That is, if I'm reading this correctly, and I'm not yet certain that I am.

One thing that I want to do, and it's clear to me how I'd do it with conan (or pip) but not yet clear to me how I'd do it with vcpkg, is have a version of a package that's available in a public repository also be available in my internal repository with some added private patches, and have my version "win" for my projects.

Our recurring need for this is when we're building out patches that we want to have incorporated upstream but aren't ready to do that yet for one of many reasons.


It doesn't need Python. My C++ compiler is good enough.

I don't like package managers that force me to install a programming language just to use them.


We've been using vcpkg on Windows and it's really made the process of managing c++ dependencies far less painful. Great to see this coming cross-platform as we can now simplify the dependency section of our install guide to one line.

vcpkg install boost cgal [etc...]

Their team has also been super friendly and responsive on Github. Looking forward to seeing where this goes.


Thank you Microsoft. This is awesome


I guess this is the part where they Embrace the overwhelming trend towards cross-platform tooling.


I see the Windows Subsystem for Linux as the Embrace step, making this the Extend step.


Google is much further ahead than Microsoft on the Extend step regarding Linux.

ChromeOS, Android, Android Things.


> At Microsoft, the core of our vision is “Any Developer, Any App, Any Platform”

This is what you want us to believe. But this makes little sense: if you really believed in "any platform", this would go against your the interest of the company (Windows sales), and therefore also against the interest of shareholders. I liked you more when you didn't pretend.


DevDiv stil operates as its own business - and the profit margins for licenses for Visual Studio (and Azure subscriptions) is higher than Windows. The bulk of Microsoft’s Windows license fees come from OEMs anyway.


Also, don't forget that DevDiv is the oldest Microsoft, maybe the truest Microsoft. Microsoft's first products were all programming languages/environments. If Microsoft's DevDiv should outlast Windows, that may be poetic.


It's a shame that this is the kind of comment that is posted on what could be a genuinely decent tool for solving a problem that is still not solved for C and C++.


I like the tool, really. I don't know why they didn't choose to support Conan, but I guess they had a good reason to create their own tool from scratch.

On the other hand, I've lived long enough to see the same tricks played my MS and not to trust them with anything. This "any platform" seems particularly double-faced when Linux is almost 30 years old but you still have to install it after Windows in multiple-system setup because Windows doesn't believe any other system could exist.


Because many in the community dislike the dependency on Python.

C++17 is powerful and user friendly enough for writing such a tool.


> this would go against your the interest of the company (Windows sales)

This would've been an insightful comment in 2007, but the world has changed. Microsoft makes its money on Azure now, and that means supporting developers everywhere.

For crying out loud, post-reorg Windows doesn't even have someone reporting directly to the CEO anymore.


The fact that they make money on Azure made them do some Linux(kernel)-related work. It made them join Linux International. But it's because they had no choice, not because they wanted to or suddenly stopped believing in vendor lock-in.

If they want to be competitive, they have to offer easy migration options from other cloud providers (Azure Migrate). What is everyone else running? Linux. So Microsoft has to do it, too. What determines popularity? To a large extent, winning the hearts and minds of developers. MS always understood this. As developers changed, MS needed to change the way they talk to them, that's it.


If that was true then WPF and WinForms would have been part of .NET Core.

If that was true then Microsoft wouldn't be pushing DirectX 12.


> WPF and WinForms would have been part of .NET Core

I’d love them to be, but unfortunately there’re technical reasons for that. Both depend on too many Windows components. WinForms is really a thin wrapper around Win32 windows and GDI+. WPF relies heavily on DirectX 9.

For mobile platforms, Microsoft offers Xamarin for GUI.

> Microsoft wouldn't be pushing DirectX 12.

Again, there’re technical reasons. For the same reasons Apple is pushing Metal, and Khronos is pushing Vulkan, all 3 are conceptually quite similar.


> I’d love them to be, but unfortunately there’re technical reasons for that. Both depend on too many Windows components. WinForms is really a thin wrapper around Win32 windows and GDI+. WPF relies heavily on DirectX 9.

And yet somehow Mono is able to (mostly) emulate WinForms, while Wine can (mostly) emulate D3D9. And MS can't (at least) throw their weight behind that, rather than wasting time on WSL?

> Again, there’re technical reasons. For the same reasons Apple is pushing Metal, and Khronos is pushing Vulkan, all 3 are conceptually quite similar.

So why aren't Microsoft (and Apple) pushing Vulkan as well, rather than their own "quite similar" APIs?


> MS can't (at least) throw their weight behind that, rather than wasting time on WSL?

I don’t know the answer to that, I’m unrelated to MS, not even on the same continent. But I have an idea why. Because outside Android, Linux GPU stack is a mess. Maybe Vulkan will fix it, but it’s not happened yet. I’m just not sure it’s possible to build a good product on top of that.

But they sure can build a single cross-platform GUI library for Windows, OSX, and mobile platforms. And I hope they will.

> why aren't Microsoft (and Apple) pushing Vulkan as well, rather than their own "quite similar" APIs?

Apple released Metal in 2014. MS released DX12 in 2015. Vulkan was first announced in 2015, and they released 1.0 version of the spec only in 2016. That’s why.


> Again, there’re technical reasons.

That's interesting. For one, MS has a long history of using DirectX to force people to buy the next version of Windows. Second, DirectX 12 seems to deliver uneven results when benchmarked against DirectX 11. Some go even as far as say it's just plain worse than the previous version. Nevertheless, MS will do what they can to make people switch to Windows 10, no matter what people really want, and what their personal and business needs are.


> DirectX 12 seems to deliver uneven results when benchmarked against DirectX 11.

Same applies to Vulkan.

https://www.anandtech.com/show/10047/quick-look-vulkan-perfo...

https://www.pcgamer.com/doom-benchmarks-return-vulkan-vs-ope...

And that’s understandable.

If you’ll just port a DirectX 11 game engine to 12 (or an OpenGL game engine to Vulkan), without drastic redesign of renderer, you’ll unlikely gain huge performance improvement, if any at all, compared to the older technology. The renderer need to be designed quite differently to benefit from these new multithreading focused low overhead GPU APIs, be in VK, DX12 or Metal.


Except that it shouldn't be related to Windows 10 at all. MS did the same with DirectX10, forcing people to change their systems to Vista (for some reason they call it an "upgrade"). Eventually it turned out DirectX 10 actually can be run on Windows XP and it was just a ruse on the part of Microsoft to make people buy Vista.


> it shouldn't be related to Windows 10 at all

Let’s compare with Vulkan on Linux, I hope we all agree Microsoft has nothing to do about them.

Intel Vulcan drivers for Linux require at least kernel 3.10, released in 2013.

nVidia Vulkan driver requires Linux kernel version 3.13+.

Should Vulkan support be related to Linux kernel version? Probably not, but it still is.

> forcing people to change their systems to Vista

They haven’t forces too many, Vista never surpassed XP (1). And around 2009, average installed RAM amount exceeded 2GB (2), I think more people upgraded the OS because of the 64 bits. I know about XP 64, but the software & driver support just wasn’t there.

(1) https://en.wikipedia.org/wiki/File:Operatingsystem_market_sh...

(2) https://techtalk.pcpitstop.com/2016/10/05/average-pc-memory-...


Linux kernel upgrades are free, has an iron policy on userland regressions, and aren't bundled with malware. That's a pretty big difference with requiring Windows "upgrades".


> Linux kernel upgrades are free

Windows 10 upgrade was also free for a couple of years.

> has an iron policy on userland regressions

GPU drivers include a lot of code running in the kernel. And Linux doesn’t give a damn about broken device drivers, especially third-party binary drivers, like GPU ones.

> aren't bundled with malware

Windows kernel is not bundled either. And Linux userland sometimes is, e.g. https://news.ycombinator.com/item?id=4558049


They honestly aren't pretending. Linux bash shell is on windows now, Azure runs on linux servers, etc.


Yet another package manager for Linux/MacOs to put yet more duplicates of already packaged software on our disks. As a solution for Windows, vcpkg fills a gap (I use it myself). For other platforms, this just adds more waste.

And the first thing it does on Ubuntu 16.04 is to force me to install g++-7 from the toolchain ppa. So now presumably I have to link everything statically (ever tried that with gtk?) or the users of my software will have to install g++-7 too?


"For other platforms" is not a synonym for Linux, there are plenty of other OSes out there, the majority of which still don't use package managers.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: