After thinking about it a bit, not sure actually.

• We really don't want to encourage people to use MFC
• Which group of people does this target? Either you work on a C++ project, then you have that project at hand and that's probably what you will open in KDevelop. Or you don't, then you don't have MSVC installed either and can't compile the MFC sample anyways.

Maybe we should instead have two checkboxes in the installer, "install CMake", "install Qt"? That'd be useful I think.

I just tried whether we can compile the Standard/C++/Cmake example easily. We can't. CMake tries to use cl, fails, and I have no idea how to make it use mingw from inside kdevelop. :/

It uses "NMake Makefiles" generator by default, that's why it is looking for cl.exe. It is possible to set default generator in CMake plugin settings, but it has no effect due to T1315

I actually think using cl.exe is fine, it just has to work somehow. One can add three magic lines to CMakeLists.txt which execute the VS environment setup script, then kdevelop just needs to invoke the make program properly. That currently fails, since it tries to call nmake, which is not in $PATH.

Invoking cmake --build fails too because it adds the -j option before the --build, and then cmake somehow ignores the --build.

One can add three magic lines to CMakeLists.txt which execute the VS environment setup script

I don't like this approach. CMakeLists.txt created by KDevelop should not contain any specific hacks just to please our IDE.

Me neither. But can you think of an approach you like?

We could maybe start KDevelop in the environment required by e.g. cl (aka install a "KDevelop -- Visual Studio 2015 compiler" shortcut in the start menu). Would that be better?

If i understand it right, the configuration step works, that is CMake knows how to find MSVC without any environment hacks.

If so, then it is cmakebuilder who is causing the trouble, and it should be fixed. How about asking CMake of what CMAKE_MAKE_PROGRAM value has and then using it?

No, it doesn't. The config step also just works if you execute vcvars.bat before.

No, it doesn't. The config step also just works if you execute vcvars.bat before.

Can you, please, share the error that is emitted when configuring in clean env?

In T3534#53795, @brauch wrote:

Me neither. But can you think of an approach you like?

We could maybe start KDevelop in the environment required by e.g. cl (aka install a "KDevelop -- Visual Studio 2015 compiler" shortcut in the start menu). Would that be better?

Hmm, this is probably not a bad idea, never thought of that. Unfortunately we would need to figure out which VS versions are installed at the install time of KDevelop. I don't see an easy way to make that reliable (you can always install VS *after* installing KDevelop, too).

@arrowdodger :

C:/Users/sven/projects/test5/build> "C:/Program Files/CMake/bin/cmake.exe" "-DCMAKE_EXPORT_COMPILE_COMMANDS=ON" "-DCMAKE_BUILD_TYPE=Debug" C:/Users/sven/projects/test5
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
  The CMAKE_C_COMPILER:

    cl

  is not a full path and was not found in the PATH.

  To use the NMake generator with Visual C++, cmake must be run from a shell
  that can use the compiler cl from the command line.  This environment is
  unable to invoke the cl compiler.  To fix this problem, run cmake from the
  Visual Studio Command Prompt (vcvarsall.bat).

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:2 (project):
  The CMAKE_CXX_COMPILER:

    cl

  is not a full path and was not found in the PATH.

  To use the NMake generator with Visual C++, cmake must be run from a shell
  that can use the compiler cl from the command line.  This environment is
  unable to invoke the cl compiler.  To fix this problem, run cmake from the
  Visual Studio Command Prompt (vcvarsall.bat).

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "C:/Users/sven/projects/test5/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/sven/projects/test5/build/CMakeFiles/CMakeError.log".
*** Failure: Exit code 1 ***

@kfunk : We could just have one batch script for VS (selecting the newest VS installed automatically) and one for mingw, and when you invoke either without having the toolchain installed it displays a message box informing you that you are missing the toolchain. I think that would be acceptable behaviour.

More problematic is that I don't even know how I would run KDevelop in that environment :/ just ". vcvarsall.bat" and then "kdevelop.exe" in PS doesn't seem to work, still the same error.

Aha. When configuring with "Visual Studio 2015" generator, CMake finds the compiler even in clean environment. This confused me and i was wondering why are you getting this error.

How about modifying cmakebuilder to work with .sln/.vcxproj files? Judging from my experience with emerge this shouldn't be too hard.

In T3534#54004, @brauch wrote:

just ". vcvarsall.bat" and then "kdevelop.exe" in PS doesn't seem to work

Yes, i still haven't found a way to run batch scripts in PS properly.

For NMake generator we could fire up a cmd.exe that would first source vcvarsall.bat and then run cmake.exe.

Yes, I just tried that, it works. You can run cmd, "call vcvarsall.bat", then run kdevelop and you can just build and run with cmake.

I think we should do that for now. Install a "KDevelop (Visual Studio compiler)" shortcut which has a script doing that, create maybe a wrapper which displays a dialog box if no MSVC was found, and be done with it. That at least gives people one clear way how they can build something.

I'd rather run CMake this way, not whole KDevelop. We also need to locate that vcvarsall.bat somehow and it would be easier to do this from C++.

There's an environment variable, $VS140COMNTOOLS.

Well, if we only run cmake that way, we need UI in kdevelop to select this ... no? That's why I suggested the batch script ...

Yes, that's what i'm imaging for the end result. There would be additional field "Environment" or something like that, that would allow him to select between "MSVC", "MinGW" or "None".

But for now running whole KDevelop in the modified environment will surely do, i agree.

See added diffs. Here's an installer if you want to try it out: http://files.svenbrauch.de/kdevelop-windows/kdevelop-x86-5.0-7a9fc40-vc140.exe