Vcpkg: Is vcpkg dead?

[zhulika]

Is this project dead?

I posted a couple of questions over three weeks ago that are showstoppers for me to use vcpkg and I haven't heard anything.

[Voskrese]

Support? )))

[tara-raj]

@zhulika vcpkg is indeed very much alive. Sorry we haven't gotten back to you sooner. We're swamped with issues and PRs and are first triaging the issues and commenting on PRs as they come in. The team is focusing on closing/accepting "high impact" issues/PRs first. Thank you for being patient, and I hope the team can get to your questions soon! Mind linking the questions you asked here? It'll help us get to them quicker. I found one but not the other

[Voskrese]

@tara-raj

Some checks were not successful
1 failing and 1 successful checks
Vcpkg-PR-Eager — failed

Details ???

Better make the error output by applying log files
To be able to see exactly what errors were admitted during the porting
Because the local build is successful and what you have on the server is not clear at all

[patrikhuber]

@tara-raj Is VS 2019 supported yet in vcpkg? VS 2019 came out more than two weeks ago, with the Preview having been out for months, and it would be a real no-go if it wasn't supported yet. I see some potentially worrying issues like #6078. Also the main page Readme still says "Prerequisites: VS 2015U3 or 2017" and doesn't list 2019.

[Neumann-A]

The CMake version included in VS2019 does not even support VS2019 and people are worried that vcpkg is not supporting it.... Even if libraries build with vcpkg are compiled with VS2017 they will work fine in a project using VS2019 due to binary compatibility.

[degski]

The CMake version included in VS2019 does not even support VS2019 and people are worried that vcpkg is not supporting it.... Even if libraries build with vcpkg are compiled with VS2017 they will work fine in a project using VS2019 due to binary compatibility.

@Neumann-A The situation is more irritating than that. With a side-by-side install (17/19), vcpkg tries to build with VS19, using the VC17 included cmake (cmake-3.12.4).

I'v raised an issue [on the MS thingy (via the IDE)] and have equally suggested to update both to cmake-3.14.1 and to keep them synced at all time (to avoid issues). I have also mentioned that this causes issues in vcpkg.

[Neumann-A]

@degski I probably never saw an issue with that because I have a separate CMake installation on the path although I have a side-by-side install of VS2017 + VS2019. vcpkg is happily using the separate one. So to me it seems like having a standalone installation of a current CMake version on the PATH works as a workaround?

[degski]

@Neumann-A How did you do that? I have a standalone 3.14.1 install as well, but it still tries to use the VS-supplied one(s). Your standalone, is it 32- or 64-bit [mine the latter]?

[Neumann-A]

@degski Don't know just works. 64 Bit version. Be sure to add CMake to the PATH variable for all users.
(I inspected the path variable and there is no VS path in the path variable. )
here one line from one of the config logs.
[1/2] cmd /c "cd .. && "C:/Program Files/CMake/bin/cmake.exe" "G:/vcpkg_test/vcpkg/buildtrees/abseil/src/4345461f32-f9655ed6fe" "-DCMAKE_MAKE_PROGRAM=C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe"

[degski]

@Neumann-A Thanks for the feedback. Sure it's added to the path, one of the first entries. I wished VS doesn't ship with these things [like ninja] and simply prompts the user to install those from the original source. When I feel like it, I'll do some more digging, there must be a reason.

[Voskrese]

set VSCMD_DEBUG=1 or 2 or 3

call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"

[DEBUG:VsDevCmd.bat] calling "ext\cmake.bat"
[DEBUG:ext\cmake.bat] init:COMPLETE

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\vsdevcmd\ext

...
:export_path

if not exist "%VSINSTALLDIR%Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin" goto :error_setting_path
if not exist "%VSINSTALLDIR%Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja" goto :error_setting_path
set "PATH=%PATH%;%VSINSTALLDIR%Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;%VSINSTALLDIR%Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja"
goto :end

:error_setting_path
...

rename *.exe

"%VSINSTALLDIR%Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin"
"%VSINSTALLDIR%Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja"

Do not delete folders, otherwise the check will not be passed

[zhulika]

@tara-raj. Thank you for your reply. The two questions that I asked were: #5714 and #5715.

I have now received a reply to #5715 but no response to #5714, yet.

The one about "integration" is not as urgent as the issues that I have with your version of libsodium, but it did lead me to wonder whether vcpkg was still a supported product as it refers to compatibility with VS2019 and not some third-party product. I'm pleased to hear that you are still with us, though!

[ras0219-msft]

@patrikhuber @degski We've updated to CMake 3.14.0 since one week ago[1], which brings general support for VS 2019[2]. If there are any remaining issues, please let us know specifically so we can fix them!

Additionally, if you'd like to force vcpkg to continue using a side-by-side VS2017 instance, you can use the VCPKG_VISUAL_STUDIO_PATH triplet setting to specify exactly which instance to use.

[1] https://github.com/Microsoft/vcpkg/pull/5702
[2] https://cmake.org/cmake/help/v3.14/release/3.14.html
[3] https://github.com/Microsoft/vcpkg/blob/master/docs/users/triplets.md#vcpkg_visual_studio_path

[degski]

@ras0219-msft Thanks, Robert... Will give it a go as soon as something needs upgrading (and is not Boost). Don't really see a need for using 17 over 19, but thanks for the option at least [for the moment I'm waiting for MKL and TBB (the Intel built ones) to catch up, for switching over to 19]. Yes, Sir, works great [again] now, thanks.