This is a short one and probably doable as a Summer of Code project.
The idea: add support for the Microsoft compiler and linker and Visual Studio projects and solutions (.sln, .vcproj, et)c in KDevelop, at least in the Windows version.
QtCreator has suport for the first part (compiler and linker).
For the the second part (solutions and projects), code can probably be derived (directly or indirectly) from MonoDevelop‘s and CMake‘s. The starting point would be MSBuild support, as it’s what VS2010 is based on.
Bonus points if you add C#/.NET support (Qyoto/Kimono).
That’s not really going to happen. We can support workflows with qmake/cmake+make on windows, but not to msvc the same way as we don’t have specific options to support GCC.
About C# support, we have something done, but it’s old and unmaintained. Maybe it’s something not that important…
but not to msvc the same way as we don’t have specific options to support GCC.
MSVC solution and project support would be implemented at the same level of abstraction CMake is. The reason? It is possible to use, for instance, gcc or icc (the Intel compiler) with .vcproj/.vcxproj.
MonoDevelop does not support C/C++ projects from Visual Studio. Neither vcproj (2008 and earlier), nor vcxproj (2010 and later).
In Visual Studio, C/C++ projects are close enough to C#/.NET projects that you can reuse large chunks of code (at least the ideas for the implementation, because MonoDevelop does not use Qt/KDE either).
Please, stop using the planet as a wishing place, we already have the bugzilla for that.
For nmake all one has to do is add a few more regexps (if at all) to the make-builders error/warning check.
And disabling the parallel support I guess since nmake doesn’t do that.
Then cl/link “support” would be done, hardly a project for gsoc.
.vcproj support is a different matter. It requires constant reverse-engineering of the format and with every new VS version there’s quite some effort to support it (as can be seen by cmake). The CMake developers face different problems that are not easily explainable or workarounded on each new version. For an OSS project like KDevelop you’ll have a very very hard time finding a volunteer to do this work. Especially since Windows is such a developer-hostile environment for C/C++.
Andreas,
.vcproject and .sln for VS2008 (and probably back to VS2002) is documented and public. I’d say it’s not really interesting given that those compilers are old.
.vcxproject and .sln for VS2010 is also documented and public (it’s MSBuild) and IMHO these are worth adding support.
I’d say implementing the MSBuild-based support for .sln and .vcxproj is a good GSoC: not too big, not too small.
Isn’t MSVC already supported – just configure cmake to use MSVC?
Please re-read the post. I’m not talking about CMake projects which compile using MSVC but about opening .sln and .vc(x)proj directly.