Reconsider cross-platform stance

[ghost]

Saying "we don't want to duplicate the apt-get on Linux" makes a lot of sense as a reason why vcpkg is not cross-platform.

Except, when it comes to managing dependencies, versions, and how to refer to them from your project / CMake, vcpkg and apt-get are not that alike at all. For someone working cross-platform, having to test in different way, instruct their users how to build in different ways etc. is not helpful.

And since vcpkg builds upon CMake, making it cross-platform should at least technically not be hard.

vcpkg appears very well thought out, it be great to take the benefits of this to C++ developers even further.

[Telokis]

The current version of vcpkg depends heavily on Visual Studio 14. A quite big rewrite of the code would be needed. But, for sure, it would be a nice thing.

[ghost]

I'm sure it depends on it for the direct VS integration, but for the package management and building using CMake? It would appear to me that is easy to make work on other platforms.

[urajendran]

Want to add one vote for a cross platform version.

Thanks Uday

[adam4813]

The one HUGE advantage vcpkg has over apt-get or similar is that the others have libraries tied to the particular distribution and adding out of distros packages can be cumbersome at best. With vcpkg the libraries available and the version is only limited by the commit you have checked out.

TL:DR with vcpkg you can have a broader range of libraries and versions available with a much more streamlined process.

[ras0219-msft]

I want to first thank everyone for giving feedback on this issue, please continue to do so! Your scenarios and thoughts here do make a difference.

Additionally, while we still have no plans to support cross platform, I'd be happy to accept code contributions that reduce vcpkg.exe's dependency on Win32. Please keep in mind that the const char* Win32 functions generally do not accept utf8, so the code will still need to manipulate const wchar_t*s at that boundary.

We are currently using MSBuild in order to ensure as frictionless of an initial install experience as possible, however in the future we can use the bootstrap powershell script to download a copy of CMake during the initial vcpkg.exe build, enabling us to use CMake and still preserve the VS2015-only acquisition experience.

[rwebber]

I would love to be able to use vcpkg cross platform. That said.. its great. Thank-you!

[usernameiwantedwasalreadytaken]

+1

(for linux)

[noeffn]

+1

The one thing im missing is a cross platform package tool for c++ that enables one to easily manage libary dependencies and vcpkg could be this tool. Interpreter and scripting languages have Composer (php), npm and yarnpkg (js), Gems (ruby) but there is no tool for C++ in general (cross-platform)

[sjohnsonaz]

+1

[cmazakas]

At first I was very against vcpkg for Linux but then I realized the true power of the tool. vcpkg lets developers create isolated and sandboxed environments for developing software without messing up what's in the users /usr/lib, etc.

Because of that, I'm wholeheartedly in favor of bring vcpkg to Linux and OSX as its convenience and power have yet to be fully replicated. Mind you, it will still be up to individual developers to ensure that their applications work outside the sandbox created by vcpkg.

[bagong]

Mind you, it will still be up to individual developers to ensure that their applications work outside the sandbox created by vcpkg.

This is the really thorny side of it. It will be difficult to avoid conflicts, except if you link everything statically. There is not even a concept of a "application folder" on Linux, so you'd have to brush everything against the norm. Not very promising. Linux is not designed for a "sandbox logic" ;)

[aardappel]

There are crazy people out there (e.g. myself) who link as much statically as possible, on every platform. I'm sure those same people would welcome a cross-platform build sandbox :)

[aardappel]

A simpler argument for cross-platform vcpkg is: "why not?". Let people decide themselves if using it on Linux or OS X makes sense, depending on the libraries they link, and wether they're being linked statically or not, etc. My dependencies include things which are not even available through apt-get, let alone in the right version.

[MikeGitb]

I guess the current reason for "Why not" is that someone would need to spend the effort of porting and maintaining vcpkg for other platforms. Not saying I wouldn't like to see a cross platform vcpkg as well.

Have you tried Conan?

[schoetbi]

I aggree with MikeGitb that Conan has many advantages: I am not sure how it compares to vcpkg but for me it seems that with vcpkg one is more tied to first windows and also to visual studio. Please correct me if i am wrong.

Conan on the other hand is:

• Compiler neutral
• Operating system neutral
• Support for Rust/Go
• Decentralized
• Internal caching of packages with private repositories
• Support for many different build configurations
• Use of hashes to detect already build packages securely

See this for more information:

• CppCast 56
• CppCon2016

[bagong]

Is there anything stopping people from forking vcpkg to become cross-platform? ;) If I were MS, I wouldn't do it. I think it's actually a good sign of their attitude. Conan can make use of vcpkg, I think they can complement each other. Just let adoption decide, that's how it's going to happen anyways...

[MikeGitb]

Just to clarify this: I didn't say Conan had any particular advantages over vcpkg (except for its cross-platform nature). Just that if you need a cross-platform package manager right know, Conan might be a more realistic solution than waiting for vcpkg to become ported.

Even if MS or someone else would invest the resources to translate all concepts to linux, this won't happen overnight.

[aardappel]

There's a gazillion attempts at C++ package/dependency managers out there, but all of them are in a perpetual state of few people using them, Conan included.

To really benefit from a package eco-system, it helps if one of them becomes a common standard, like in other languages.

vcpkg appears better designed than most, is simple / easy to use and understand, is CMake based, does not require a Python install, has nice VS integration / is backed by MS etc, so certainly could fill that role.. if it were cross-platform.

[schoetbi]

@aardappel: I think the decision of Cmake to have it's own language is a waste. Python is well suited for this and you can reuse your Python knowledge and are not forced to learn another language.

To get such an ecosystem I guess you are right that an organization should be responsible for the development. Kitware does a good job here with Cmake.

You said that vcpkg is better designed than most. Did you also mean Conan? If so maybe you can share your design comparison conan vs vcpkg?

[aardappel]

@schoetbi CMake's value is that is ubiquitous, unlike its alternatives. I think we can all agree its language is terrible.

[navidR]

With cross-platform Vcpkg, Microsoft does have a great chance of becoming the company behind of de facto package management utility for C/C++ development. I don't know why they hesitate, or why they didn't start this project as Cross Platform. But one thing is for sure: C++ does require a solid package management, and I think Canon/Bintray saw this opportunity.

[cmazakas]

Is the fear that with Linux, we might be prone to incorrectly linking to a system lib that we didn't intend to? That might be potentially catastrophic but it should be easily mitigated.

I guess this is all because Linux makes dynamic linking just too easy :P

[ras0219-msft]

@bagong @LeonineKing1199 rpaths are one possible solution on Linux and osx to get the windows "applocal" behavior, if I remember correctly. Static linking by default would also work, of course 😀.

We chose cmake because most open source libraries that support msvc use cmake, so it is already on the list of things you need to know as a maintainer (the only other being C++). It then has the bonus that it is cross platform, so we haven't designed ourself into a windows-only corner. The syntax certainly leaves a lot to be desired, but it is at least legible to new users, which is a requirement.

As a total aside, I would really love to see a nice cmake transpiler in the future (E.g. Typescript).

[eric-vader]

+1

for Open source and Fedora Linux support! C++ is missing a cross platform tool like this!

[IvanBoyko]

+1

[GabrielJadderson]

+1

[rgozim]

+1

[syegres]

+1

[MikeGitb]

C++ is missing a cross platform tool like this!

What about Conan?

[GOOD-Stuff]

+1

[ras0219-msft]

Thanks to the efforts of @atkawa7 and others, vcpkg is buildable inside WSL!

The details are in https://github.com/Microsoft/vcpkg/pull/1528, so please try this out and give feedback ☺

[jwtowner]

Nice. Since Visual Studio 2017 supports building for Android & Linux, and there is now Visual Studio for Mac, what about adding support to vcpkg for other triplets targeting Android, Linux and macOS/iOS that use the same tool chains bundled with VS? Would it be possible to generate Nuget packages for these platforms as well? Would definitely ease cross-platform package management, giving us a one-stop-shop for acquiring, building and deploying versioned binary packages via a locale Nuget server for consumption into MSVS projects.

[pahlevan]

+1

[jclay]

For those that didn't see it, this is now supported: https://blogs.msdn.microsoft.com/vcblog/2018/04/24/announcing-a-single-c-library-manager-for-linux-macos-and-windows-vcpkg/

[ras0219-msft]

Thank you to everyone who has contributed to this issue! I'm closing it as "sufficiently reconsidered 😉".

[angelmixu]

Just saw the news of support for linux and macOS, and as in the article above suggested, I came to comment my experience.

In the company I'm working right now we have some products for Windows, macOS and iOS, with a port to Android in the near future, and in few time, we're porting to GNU/Linux some of our apps. So as suggested above, adding iOS and Android targets would be awesome. I'm porting our Windows dependencies to using vcpkg and so far I'm very happy with the results :)

Also in other jobs I was, we made videogames for mobile phones, so Android and iOS development using C++ would benefit a lot of an iOS and Android target, and we could share the same system for development (Windows) and for deployment.

Thanks for your effort on improving vcpkg!

[rezzeted]

Please add support iOS and Android, in the project of my company we are working on a croplatform application and now the process of adding a new library is extremely tedious. Support iOS and android will allow us to use vcpkg.

[ghost]

At first I was very against vcpkg for Linux but then I realized the true power of the tool. vcpkg lets developers create isolated and sandboxed environments for developing software without messing up what's in the users /usr/lib, etc.

Anyone on Linux should consider using Gentoo's portage for this. In comparison vcpkg seems fragile and very limited.

[aksswami]

+1 for Android and iOS.

[MikeGitb]

I haven't done any developments for mobile devices, but for libraries that can be built with cmake: Would this require anything but a different toolchain file?

The port to linux was IIRC mainly about supporting linux as a host platform (although I guess build instructions for some ports also had to change significantly).

[aksswami]

I think you are right as per my very limited experience for android compilation. We only need specific toolchain file for the platform. It would be great, if we have some documentation or example around this. Example cpprestsdk provides supports for Android via cmake toolchain file, maybe we can take pointer from there.