CMake or vcpkg support

[MarkIngramUK]

Will there be distribution via vcpkg too? Or at least consideration for cross platform projects that use CMake? Currently there is no easy way to consume nuget packages via CMake for C++ projects:

https://gitlab.kitware.com/cmake/cmake/-/merge_requests/3389#note_580524

https://developercommunity.visualstudio.com/idea/351636/use-packagereference-in-vcxproj.html

[wjk]

My 2¢: I currently am shifting to CMake for my Windows-only projects, precisely because vcxproj is so old and awkward to use. Requiring NuGet and therefore vcxproj is currently a big annoyance for me vis-a-vis cppwinrt, and I will have to fork the codebase to make it work in a CMake-based build. I would greatly appreciate it if care would be taken to ensure compatibility with non-MSBuild build systems, and possibly non-Visual Studio dev setups. (Yes, VS is the market leader for a good reason, but other IDEs do exist, and I sometimes use them as well.)

Furthermore, I am currently attempting to shift my Windows-based C++ projects so I can crosscompile them from a Mac using clang-cl and mingw-w64. I used to be able to use a VM to develop for Windows natively in Windows, but Apple’s move to ARM has put the kibosh on that approach, and I don't want to have to buy another laptop. (I currently do my Windows development on a desktop PC via RDP, but using only that method means I can't work on my Windows projects on the go.) Therefore, any use of C++/CLI or MSVC-only C++ language extensions makes my day even more hard. Thanks!

[mevey]

Hey @MarkIngramUK and @wjk, we've made this a feature proposal and moved it to our backlog to review later as we will focus on NuGet first.

[mevey]

I don't think I meant to close this. Sorry about that.

[wjk]

@mevey The updates to vcxproj and to vcpkg made in the Visual Studio 16.3 previews have actually made use of vcxproj tolerable again, and I am now using them instead of CMake, as vcxproj is far easier to integrate into a C# project than CMake-based builds are. The only thing that’s missing is PackageReference support, which has been requested for a long time. However, I understand the team in dotnet/project-system is working on enabling this. Nevertheless, thank you for taking this under consideration.

[Zingam]

CMake should mean CMake/Ninja.

Original feedback on closed duped thread

Please consider improving the integration of third party build system. Currently the most interesting combination is CMake/Ninja but that might change in the future, so a future proof approach should be considered.
This is more of a Visual Studio suggestion but I think it is highly relevant as a whole. Currently it is possible to build a CMake based UWP project but it is not possible to debug it.
I would like to be able to build/debug and test all sorts of CMake/Ninja C/C++ projects from Win32, UWP, WSL to Xbox right from Visual Studio without the need to generate .sln, etc.
Visual Studio has excellent CMake support but then CMake/Nuget/C++/MSBuild/vcpkg, etc. don't really work very well together as a whole yet.

As my code is cross-platform Windows/Linux/Apple/Google, etc. I really would like to have a complete, unified build/test and deploy experience based on CMake/Ninja preferably (at least until somebody comes up with a better build system).

[stevenbrix]

@wjk, what is the process of moving to CMake like? Is it fairly straightforward? I'm no fan of Nuget and .vcxproj for C++, but I'm even a worse fan of the following options:

1. Abandon Nuget and .vcxproj and make all C++ customers move to vcpkg and CMake w/o a path forward
2. Try to support both Nuget/.vcxproj and vcpkg/CMake environments for C++ customers.

I haven't personally spent enough time with CMake/vcpkg to really have an opinion on what it's capable of or its downfalls are, so I rely on the opinion of others. The cppwinrt team tried to adopt/support cmake a few years ago and the effort failed, but it's possible times have changed. My understanding is that CMake is just a wrapper over MSBuild, so what are the real benefits?

The updates to vcxproj and to vcpkg made in the Visual Studio 16.3 previews have actually made use of vcxproj tolerable again, and I am now using them instead of CMake, as vcxproj is far easier to integrate into a C# project than CMake-based builds are. The only thing that’s missing is PackageReference support, which has been requested for a long time. However, I understand the team in dotnet/project-system is working on enabling this. Nevertheless, thank you for taking this under consideration.

@wjk this is generally how I feel too. If .vcxproj had VS IDE support for PackageReference, then I think that would be pretty awesome.

[wjk]

@stevenbrix Moving to CMake is fairly straightforward as the syntax is much cleaner — if, and it's a big if, your project is 100% C++. If your C# project depends on a CMake component, you’ll need something like this to pass files into MSBuild-land. Clunky but workable.

But if your CMake component depends on a C# project to build, abandon all hope — there is no way I know of to integrate a modern C# project into a CMake system. The CMake docs suggest that you write out a Frankenproj file with CMake @something@ placeholders for paths and whatnot, then call configure_file() on it and then add the generated result to your solution using some CMake command I cannot remember. Yuck. However, you cannot simply integrate a C# project as-is, as it would need to have output paths replaced by CMake using configure_file() or CMake would not be able to find the outputs. CMake projects cannot assume anything about what path they are being built in, except that it mirrors the source code structure directory-for-directory.

I suppose if you really wanted, you could use add_external_command() to call MSBuild.exe and pass all the relevant parameters as command-line arguments, and use the OUTPUTS argument to pass the files back into CMake-land. But for .NET apps this quickly becomes untenable, as projects often output dozens of files, each of which must be specified manually in the CMake file.

Really, all we need is for someone in the Visual Studio MSVC team to flip whatever switch is needed to enable PackageReference support in vcxproj, as all of the required components have been implemented; vcxproj just refuses to use them. And there is no sign that they will ever do this. Hope this helps!

[Zingam]

CMake just works. It is a build system generator. You want to use MSBuild you generate .sln and byild. You want ninja - it just works. You want make on Linux or Mac - it just works.
And you have everything in a plain text. So far so good.
The language that CMake uses is horrible. It is easy but very annoying to use.
If you just need to work on Windows. CMake might not make much sense to you. For all other cases it is a tool that just works.

[llothar]

CMake just works.

Only use it on Linux and Android.
Don't use it on MacOS or Windows. Or always be years behind with new features. All the I18N on XCode still don't work after 8 years.

[MarkIngramUK]

CMake is actually really nice and easy to use, if your project configuration is fairly straight forward. Just add your files to targets, then add dependencies between your targets. Things get complicated if you're mixing languages, or if you need to depend on third party code. And given the "Open CMake Folder" support in Visual Studio, it's really easy to work with now.

[Zingam]

Or you could use it with Visual Studio Code on Mac, Linux and Windows as I do. VSCode has a descent although lacking support compared to VS ( why did they had to name it Visual Studio Code)?
Debugging, running GTests in Visual Studio Code with CMake is actually quite good.

[Zingam]

Or this could be generalized as: Enable easy support of 3rd party build systems and package managers.
CppWinRT comes as a Nuget and it is impossible to use with Cmake in a sane way. Nuget cant be installed systemwide.
And I cannot get a simple CMake/Ninja automated workflow but I need to generate a VS solution and manually to install the Nuget.

[DrusTheAxe]

Those interested in CMake (or other build systems) please check out #1891 (reply in thread)

[fredemmott]

While the MSBuild documentation says "C++ and JavaScript project types are unsupported" this appears to no longer be the case; CMake's VS_PACKAGE_REFERENCES now works fine for C++/WinRT, as long as you have a very recent visual studio and CMake version.

[fredemmott]

For those wanting older versions or without the dependency on visual studio project generators or nuget: https://github.com/fredemmott/OpenKneeboard/blob/7fd38de1d1d827c100dea460ea3eb9b8032b54b1/third-party/cppwinrt.cmake

[Patschkowski]

Hi @stevewri , hope you can share an outlook on the expected timing for the implementation of this new feature. Thanks!