In D3424#90759, @antonanikin wrote:

In D3424#87489, @mwolff wrote:

Any update on this? Sounds like a useful feature

Hi, Milian, I have an updated version, but it not finished. The current state is:

1. If we doesn't want to provide docsets loading the plugin can be quickly adapted to current master.
2. Zeal's author doesn't provide it's infrastructure for docsets downloading :(
3. I have quick-and-dirty version of scripts which downloads docsets information from github repositories and convert them in "compressed" form, which currently hosted on my server. The docsets repo author agrees to provide it's stuff for our plugin with providing copyright information.
   
   Now I don't know which way is better. Some peoples also suggests to provide library/kioslave for docsets support. All this possible but with different time cost. I also agree with Rene when he suggest to add ability for external-app documentation viewer, because the internal is far from ideal :(
   
   Personally for me the ideal situation is provide "full stack" solution with our docsets information distribution server and downloading/updating docsets independently from Zeal (but if we can share docsets with Zeal it may be useful) with creating some external app (something like KDevDoc, Zeal/Dash inspired), which supports all types of documentation (Qt, man, cmake, dash docsets, etc) and provides an API to integrate it with KDevelop as internal or external viewer (user choice).

In D17908#674686, @sredman wrote:

I suspect it's not necessary to ship with KDevelop: Either Visual Studio >= 2017 is installed, in which case the vswhere tool should be on the path, or VS is not installed, in which case the tool wouldn't do us any good.

I have installed Build Tools for VS2019 and the installation is at

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools

I found this string inside HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\1eb19443 which honestly doesn't seem the proper key to extract this value but anyway.

In D17908#492410, @sredman wrote:

Actually, a pleasant surprise for today is that this whole mess of registry keys and environment variables is mostly unnecessary as of VS 2017, since Microsoft provides a tool which does all the locating work for us: https://github.com/microsoft/vswhere

In D23905#536196, @mlaurent wrote:

I rebased it and fixed conflict but it changed owner... why ??? How I can change it ?

In D23905#535610, @mlaurent wrote:

Did you have commit access?

Minimum cmake version is bumped to 3.1.0.

Some wrong tabs and spaces are fixed.

set(CMAKE_CXX_STANDARD_REQUIRED ON)

is added.

In D23905#530765, @davidre wrote:

Also CMAKE_CXX_STANDARD_REQUIRED to also set it as a requirement

In the top level CMakelists.txt I added build system support for C++14 which was necessary for the qOverload macro.

In D23905#530132, @mlaurent wrote:

You need to add
"set(CMAKE_CXX_STANDARD 14)" if you want to use C++14 in CMakeLists.txt (at toplevel)

This functionality would be great.

In D21589#492408, @sredman wrote:

Actually, there is a bit of a problem... The version of the file currently on master is bugged :(

See: https://phabricator.kde.org/D17908#492404

In D17908#492404, @sredman wrote:

@Petross404 are you still around? Do you have any documentation references for how Microsoft expects the registry to look with regard to which key should contain the Visual Studio installation path? (I don't know if such documentation even exists...)

brauch is referring to this

In D17908#401595, @mwolff wrote:

you can pick whatever you prefer for the reviews for now.

do you have commit rights? if so, please feel free to push this directly, otherwise someone from us can take care of that for you

Upload the minimum diff.

In D15976#347700, @kfunk wrote:

@Petross404 If you want to reapply the registry-reading on top of that, feel free to do so. Sorry, but I dont think I'll have time to test that. :(

I hate tο be a naysayer here, but shouldn't we not assume that VS2017 is installed in C:\Program Files (x86) so that we don't hardcode it's path? I remember my self installing VS once in another drive, because C:\ was tiny and full.

This batch file seems very clean and simple, I like it. Unfortunately I can't help reviewing this patch as I no longer have access to Windows machines and I don't a dual-boot system :(

Our script now initializes the environment correctly (at least for VS2017) even if the user doesn't run it from Developers Command Prompt. It reads Registry to find the path under which VS2017 is installed (I fear that I read the wrong variable from the Registry).

Can a windows user with VS installed, give me the content of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7?

People with Visual Studio other than Community Edition, please consider trying out these changes. If a typo or a bug exists, it should be found early.

1. The script (sadly) uses hardcoded paths for vcvarsall.bat, instead of needing VS150COMNTOOLS. This way it can be found and executed, without the need of Developer's Command Prompt.

@kfunk As I already have mentioned, clicking the script (finding it in Start menu) doesn't initialize correctly the environment. It has to be run from within Developer Command Prompt or the complete path of MSCV binaries (for the wanted target) has to be in %PATH%.

Not sure about x64 part. What if user wants x32 project? Or that is arch of the toolchain itself?