Reconsider cross-platform stance about vcpkg HOT 41 CLOSED

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.

from vcpkg.

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!

from vcpkg.

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

from vcpkg.

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.

from vcpkg.

@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).

from vcpkg.

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.

from vcpkg.

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 :)

from vcpkg.

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?

from vcpkg.

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

from vcpkg.

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.

from vcpkg.

+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)

from vcpkg.

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.

from vcpkg.

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/

from vcpkg.

+1 for Android and iOS.

from vcpkg.

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.

from vcpkg.

Want to add one vote for a cross platform version.

Thanks
Uday

from vcpkg.

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.

from vcpkg.

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.

from vcpkg.

+1

(for linux)

from vcpkg.

+1

from vcpkg.

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" ;)

from vcpkg.

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...

from vcpkg.

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.

from vcpkg.

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.

from vcpkg.

@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?

from vcpkg.

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

from vcpkg.

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.

from vcpkg.

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

from vcpkg.

+1

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

from vcpkg.

+1

from vcpkg.

+1

from vcpkg.

+1

from vcpkg.

+1

from vcpkg.

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

What about Conan?

from vcpkg.

+1

from vcpkg.

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

The details are in #1528, so please try this out and give feedback ☺

from vcpkg.

+1

from vcpkg.

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

from vcpkg.

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.

from vcpkg.

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).

from vcpkg.

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.

from vcpkg.