In an upcoming release of the Qt Visual Studio Tools, scheduled for this summer, we plan to add support for Visual Studio Linux projects. Since the introduction of the C++ Linux workload, users have had the possibility of working on Linux development in Visual Studio. This feature is of potential interest to Qt developers, given the cross-platform nature of Qt itself, which is why we are now planning to add support for it in the Qt VS Tools extension.
As to how the cross compilation actually works, when building Linux projects in VS, the build process and overall orchestration will rely on either MSBuild or CMake, in the same way as traditional Win32 projects. The build tools themselves will then run in a compilation server, accessible through SSH. For MSBuild projects, Visual Studio allows selecting either gcc or clang as the C++ compiler.
Our plan for adding support for Linux projects is to use the features included in the VS Linux development workload to expand the existing Qt/MSBuild targets. The goal is to be able to build and run Qt-enabled MSBuild projects, both natively for Windows or cross-built for Linux.
As the first step towards that end, and as a proof of concept, we manually converted a simple Qt example (wiggly) to an MSBuild project that targets both Windows and Linux. Pressing F5 will build the project for the selected target and then launch a debug session, either locally for a Windows build or via gdbserver in case of Linux.
This exercise demonstrated that it's possible to use the Visual Studio IDE to develop, build and even debug multi-platform Qt applications. Therefore, regardless of the target platform, the Qt VS Tools extension should be able to seamlessly assist with the setup and usage of Qt tools in MSBuild projects. We've also learned that the changes to the Qt/MSBuild targets, required for supporting both native and cross-platform builds, will mostly focus on the way the Qt tools are invoked. Most (if not all) of the logic that supports the integration of Qt with MSBuild will remain valid for Linux.
In this post, we've covered the case where VS is used to target a Linux host. However, given that the VS Linux workload requires only an SSH-accessible GNU toolchain, it's possible to use a cross-compiler toolchain instead of the host one. Conceivably, it should be possible to use VS as an alternative IDE for developing with Qt for MCUs. We'll explore this scenario in another blog post.
Thank you for reading and for your interest in Qt and the VS Tools extension. Please leave a comment below if you believe (or not) that this topic is relevant, or if you have any questions or suggestions.
Looking forward to this!
I cloned the project, imported the vcxproj file and tried to compile for Windows (Release) but got that eror ("The system could not find the path"). I guess it's not finding moc.exe because QTDIR is empty. I also noted that the project doesn't have the "Qt" context menu entry. I have another Qt project in the solution that compiles ok and also references QTDIR.
1>------ Rebuild All started: Project: wiggly, Configuration: Release_Windows x64 ------ 1>moc dialog.h 1>Das System kann den angegebenen Pfad nicht finden. 1>D:\Projekte\qt_vs_linux__wiggly\wiggly.vcxproj(351,5): error MSB3073: The command "\bin\moc.exe -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\atlmfc\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\VS\include" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\VS\UnitTest\include" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt" "-IInclude\um" "-I\include" "-I\include\QtWidgets" "-I\include\QtGui" "-I\include\QtANGLE" "-I\include\QtCore" "-I\mkspecs\win32-msvc" dialog.h -o moc/moc_dialog.cpp" exited with code 3. 1>Done building project "wiggly.vcxproj" -- FAILED. ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========I added QTDIR to wiggly.vcxproj.user
<QTDIR>d:\Qt\Qt5.14.2\5.14.2\msvc2017_64</QTDIR>Now I get
1>------ Build started: Project: wiggly, Configuration: Release_Windows x64 ------ 1>moc dialog.h 1>moc: Cannot create moc/moc_dialog.cpp 1>D:\Projekte\qt_vs_linux__wiggly\wiggly.vcxproj(351,5): error MSB3073: The command "d:\Qt\Qt5.14.2\5.14.2\msvc2017_64\bin\moc.exe -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\atlmfc\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\VS\include" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\VS\UnitTest\include" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt" "-IInclude\um" "-I\include" "-I\include\QtWidgets" "-I\include\QtGui" "-I\include\QtANGLE" "-I\include\QtCore" "-I\mkspecs\win32-msvc" dialog.h -o moc/moc_dialog.cpp" exited with code 1. 1>Done building project "wiggly.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========It seems QTDIR is resolved for moc.exe, but not for the -I includes, because the project file contains for instance $(QTDIR)\include\QtWidgets, but the effective command contains "-I\include\QtWidgets".
Early this is bug not being. With regards, nicholas.
My small team is VERY interested in getting our hands on this functionality. We've focused, for better or for worse, on using VS as the source of authority for all of our application projects (vcxproj) for both Windows and Linux versions. Being able to build Qt apps on Linux just as easily as on Windows would be a great improvement to our workflow.
We'd be more than happy to engage with you to perform some pre-release testing if you're looking for people to kick the tires of the new functionality. However, we are not very sophisticated Qt users.
Thank you for letting us know of your interest. You can follow progress on this functionality by watching the following user story in our issue tracking system: https://bugreports.qt.io/browse/QTVSADDINBUG-739. Some time ahead of the official release, we'll be announcing there the release of a development version that you'll then be able to try out. Your feedback will be greatly appreciated.
So make share do all posts, not only this post.
I've raised the issue internally. Thanks for bringing this to our attention! Edit: The social media links are fixed now.
You’ve said the current plan Is to support MSBuild/Linux workflows. A lot of the Visual studio team and enterprise developer teams are trying to embrace and slowly move toward the CMake-based strategy for Visual Studio and Linux. Is that on your current roadmap, or is it too early to commit to that?
Currently, our focus remains on supporting Qt development in Visual Studio with MSBuild projects. We do have on our roadmap adding support for CMake-based Qt projects, but that is not an immediate priority. For Windows developers looking to work with Qt in CMake projects, Qt Creator already provides the best developer experience for Qt/CMake, including with Windows applications.
Thanks very much for the response. That's a real serious bummer to hear, but I understand. The matrix of complex tools which C++ software teams want to use is vast. Supporting any of these integrations seems prohibitive because supporting any one integration only covers a small percentage of the total user base, and the rest of the user base feels left out. Its overwhelming to imagine being part of the planning process for integrations between vendors of complex tools like Qt/VS/etc. Good luck.