I have many Qt projects in Visual Studio, using the new Qt/MsBuild format provided by the Qt VS Tools. When compiling in my development environment, where I have the Qt VS Tools installed, everything works flawlessly (compiling from IDE and from command line).
We have a computer dedicated to nightly builds, where only the compiler and msbuild are available (no IDE nor Qt VS Tools are installed).
When compiling the projects in such computer we get an error:
QtMsBuild: could not locate qt.targets, qt.props; project may not build correctly.
Followed by several lines such as
e:********\Preferences.h(4): fatal error C1083: Cannot open include file: 'ui_Preferences.h': No such file or directory
(Project contains Preferences.ui).
How can I solve such errors when Qt VS Tools are not installed?
One solution provided by the Tools' creators is to copy %LOCALAPPDATA%\QtMsBuild into each project directory. But we are talking about hundred of projects. Doing manually, and more on, pushing them as part of the project itself doesn't sound very elegant.
One option would be to add a pre-build step that copies it from a common place into each project (and adding a **/QtMsBuild line to each .gitignore file). Again, looks like too much work.
When looking at the .vcxproj file for the Qt project you find this fragment (the reason for the solution provided by creators):
<PropertyGroup Condition="'$(QtMsBuild)'=='' or !Exists('$(QtMsBuild)\qt.targets')">
<QtMsBuild>$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
</PropertyGroup>
So, the simplest solution (without being able to install the tools), is to copy the %LOCALAPPDATA\QtMsBuild directory (from a system with the Tools installed) into the night computer (in any common place, but I decided to keep the location used by the tools) and then setting an environment variable:
set QtMsBuild=%LOCALAPPDATA%\QtMsBuild
PS: do not add double quotes to the variable (at least I had problems with them, so VS couldn't find the files).
Update 9-14-2020
I'm not sure on which version it started, but Qt projects created with (at least) the v2.5.2 Qt VS Tools fails to compile indicating that the Qt version has not been set. To solve so, you can
Copy the Registry entries from a computer with tools installed, located at HKCU\SOFTWARE\Digia\Versions.
If you will rely on a single Qt version (but that may be update globally for all projects), you can skip the Registry and just set the Qt version of all projects to $(DefaultQtVersion) (the same used in past project formats) and define an environment variable pointing to the directory of the version: set DefaultQtVersion=c:\Qt\Qt_5_15_0\Win32, for example.
I had problems in my case setting up $Env:QtToolsPath="$Env:QT_PATH\bin" fixed the problem. (It was not finding qmake for some checks). This, I think, is required when using QtMsBuild v3.3
Not sure if this info is 100% correct but may help someone.
For me to use MsBuild with Qt using QtMsBuild (not installing Visual Studio and/or VS plugins), I need to set up:
Example (PowerShell):
- $Env:PATH="$Env:MSBUILD_PATH;$Env:PATH"
- $Env:QT_PATH="D:\BuildTools\Qt\5.15.1\msvc2019_64"
- $Env:QtMsBuild="D:\BuildTools\Qt\QtMsBuild303" #303 Against visual studio project version
- $Env:QtToolsPath="$Env:QT_PATH\bin" #Support QtMSBuild , At desktop is done by the plug in
- $Env:PATH="$Env:QtMsBuild;$Env:PATH"
- $Env:PATH="$Env:QT_PATH\bin;$Env:PATH"
I hit this and got it working.
I followed #cbuchart 's advice; but needed to do a little more/different.
So here is what I did. I copied %LOCALAPPDATA%\QtMsBuild to my repo. I then edited my .vcxproj with a text editor. I adjusted the line that looks like:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
To be:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\..\QtMsBuild</QtMsBuild>
Depending on the relative location of where your project(s) are to the copied QtMsBuild directory you might want to adjust this. In my case the .vcxproj was in a directory one level from the directory that contains the QtMsBuild directory I copied.
Next in the QtMsBuild/Qt.props file I added the following:
<PropertyGroup>
<DefaultQtVersion>$(MSBuildThisFileDirectory)\..\Qt5.15.0\msvc2019_64</DefaultQtVersion>
<QtToolsPath>$(DefaultQtVersion)\bin</QtToolsPath>
</PropertyGroup>
That was added right after the opening Project tag in that file.
This was as #cbuchart mentioned something might have changed. I didn't do the Registry idea; but added those lines instead. I think it is possible to add them to a different file that gets imported before Qt.props if desired.
Now as for what this "Qt5.15.0\msvc2019_64" is; you'll need the tools, includes, libraries from a computer with Qt installed in order to build (also DLLs if your build needs to run the executable (i.e. tests)). This might be a lot of files so you can reduce it some if you know what you are doing. It might make sense to have these be put into it's own submodule or something.
After that it should uic/moc files and ultimately build (and run).
I got too. Maybe you need update your visual studio and then restart your computer ...
problem solved. reason: install 'qt vs tools' latest version but the visual studio
not support of it.
Edit:
Some people started to mark my question as a duplicate. Do not forget that many similar questions existed when I asked this one (see e.g. the list below). However, none of these answers solved my problem. After a long search I found a comment which had been ignored by all users pointing to the missing lib. Now, many months later, the comment has been changed to an answer. However, when I answered this question by msyself I intended to help other people by directly providing the solution. This should not be forgotten and so far my answer helped a lot of people. Therefore my question is definitely not a duplicate. By the way: The accepted answer within the provided link on top does not solve the problem!
Yes, i used the search:
Failed to load platform plugin "windows". Available platforms are : Error
Deploying Qt C++ Application from Visual Studio qwindows.dll error
failed to load platform plugin "windows" Available platforms are: windows, minimal
However, in my case the problem still persists. I am using Qt 5.1.1 with Visual Studio 2012 and developed my Application on Windows 7 with Qt Creator 2.8.1. Application is compiled in "Release"-mode and can be executed if directly started with Qt Creator.
However, when starting from the "release"-Folder, i get the following message:
This application failed to start because it could not find or load the
Qt platform plugin "windows". Available platform plugins are:
minimal, offscreen, windows.
Folder structure looks like this:
release
+ gui.exe
+ icudt51.dll
+ icuin51.dll
+ icuuc51.dll
+ libGLESv2.dll
+ Qt5Core.dll
+ Qt5Gui.dll
+ Qt5Widgets.dll
+ platforms
Platforms is the folder directly copied from Qt\Qt5.1.1\5.1.1\msvc2012\plugins\platforms including e.g. qwindows.dll. Does not matter if I rename it to "platform" as some other users did. Qt is still not finding the "platform plugin windows", where is my mistake?
Okay, as posted here https://stackoverflow.com/a/17271172/1458552 without much attention by other users:
The libEGL.dll was missing! Even though this has not been reported when trying to start the application (all other *.dlls such as Qt5Gui.dll had been reported).
I created a platforms directory next to my exe location and put qwindows.dll inside, but I still received the "Failed to load platform plugin "windows". Available platforms are: windows" error.
I had copied qwindows.dll from C:\Qt\Qt5.1.1\Tools\QtCreator\bin\plugins\platforms, which is not the right location. I looked at the debug log from running in Qt Creator and found that my app was looking in C:\Qt\Qt5.1.1\5.1.1\mingw48_32\plugins\platforms when it ran in the debugger.
When I copied from C:\Qt\Qt5.1.1\5.1.1\mingw48_32\plugins\platforms, everything worked fine.
The release is likely missing a library/plugin or the library is in the wrong directory and or from the wrong directory.
Qt intended answer: Use windeployqt. see last paragraph for explanation
Manual answer:
Create a folder named "platforms" in the same directory as your application.exe file. Copy and paste the qwindows.dll, found in the /bin of whichever compiler you used to release your application, into the "platforms" folder. Like magic it works. If the .dll is not there check plugins/platforms/ ( with plugins/ being in the same directory as bin/ ) <-- PfunnyGuy's comment.
It seems like a common issue is that the .dll was taken from the wrong compiler bin. Be sure to copy your the qwindows.dll from the same compiler as the one used to release your app.
Qt comes with platform console applications that will add all dependencies (including ones like qwindows.dll and libEGL.dll) into the folder of your deployed executable. This is the intended way to deploy your application, so you do not miss any libraries (which is the main issue with all of these answers). The application for windows is called windeployqt. There is likely a deployment console app for each OS.
Setting the QT_QPA_PLATFORM_PLUGIN_PATH environment variable to %QTDIR%\plugins\platforms\ worked for me.
It was also mentioned here and here.
I ran into this and none of the answers I could find fixed it for me. My colleauge has Qt (5.6.0) installed on his machine at:
C:\Qt\Qt5.6.0\5.6\msvc2015\plugins
I have Qt (5.6.2) installed in the same location.
I learned from this post: http://www.tripleboot.org/?p=536, that the Qt5Core.dll has a location to the plugins written to it when Qt is first installed.
Since my colleague's and my Qt directories were the same, but different version of Qt were installed, a different qwindows.dll file is needed. When I ran an exe deployed by him, it would use my C:\Qt\Qt5.6.0\5.6\msvc2015\plugins\platforms\qwindows.dll file instead of the one located next to the executable in the .\platforms subfolder.
To get around this, I added the following line of code to the application which seems to force it to look next to the exe for the 'platforms' subfolder before it looks at the path in the Qt5Core.dll.
QCoreApplication::addLibraryPath(".");
I added the above line to the main method before the QApplication call like this:
int main( int argc, char *argv[] )
{
QCoreApplication::addLibraryPath(".");
QApplication app( argc, argv );
...
return app.exec();
}
create dir platforms and copy qwindows.dll to it, platforms and app.exe are in the same dir
cd app_dir
mkdir platforms
xcopy qwindows.dll platforms\qwindows.dll
Folder structure
+ app.exe
+ platforms\qwindows.dll
I found another solution. Create qt.conf in the app folder as such:
[Paths]
Prefix = .
And then copy the plugins folder into the app folder and it works for me.
For anyone coming from QT version 5.14.0, it took me 2 days to find this piece statment of bug:
windeployqt does not work for MinGW QTBUG-80763 Will be fixed in
5.14.1
https://wiki.qt.io/Qt_5.14.0_Known_Issues
So be aware. Using windeployqt withMinGW will give the same error stated here.
I had this problem while using QT 5.6, Anaconda 4.3.23, python 3.5.2 and pyinstaller 3.3.
I had created a python program with an interface developed using QTcreator, but had to deploy it to other computers, therefore I needed to make an executable, using pyinstaller.
I've found that the problem was solved on my computer if I set the following environment variables:
QT_QPA_PLATFORM_PLUGIN_PATH: %QTDIR%\plugins\platforms\
QTDIR: C:\Miniconda3\pkgs\qt-5.6.2-vc14_3\Library
But this solution only worked on my PC that had conda and qt installed in those folders.
To solve this and make the executable work on any computer, I've had to edit the ".spec" (file first generated by pyinstaller) to include the following line:
datas=[(
'C:\Miniconda3\pkgs\qt-5.6.2-vc14_3\Library\plugins\platforms*.dll',
'platforms' ),]
This solution is based on the answers of Jim G. and CrippledTable
For me the solution was to correct the PATH variable. It had Anaconda3\Library\bin as one of the first paths. This directory contains some Qt libraries, but not all. Apparently, that is a problem. Moving C:\Programs\Qt\5.12.3\msvc2017_64\bin to the front of PATH solved the problem for me.
Most of these answers contain good (correct) info, but in my case, there was still something missing.
My app is built as a library (dll) and called by a non-Qt application. I used windeployqt.exe to set up the Qt dlls, platforms, plugins, etc. in the install directory, but it still couldn't find the platform. After some experimentation, I realized the application's working directory was set to a different folder. So, I grabbed the directory in which the dll "lived" using GetModuleHandleExA and added that directory to the Qt library path at runtime using
QCoreApplication::addLibraryPath(<result of GetModuleHandleExA>);
This worked for me.
I had the same problem and solved it by applying several things.
The first, if it is a program that you did with Qt.
In the folder (in my case) of "C: \ Qt \ Qt5.10.0 \ 5.10.0 \ msvc2017_64 \ plugins" you find other folders, one of them is "platforms". That "platforms" folder is going to be copied next to your .exe executable. Now, if you get the error 0xc000007d is that you did not copy the version that was, since it can be 32bits or 64.
If you continue with the errors is that you lack more libraries. With the "Dependency Walker" program you can detect some of the missing folders. Surely it will indicate to you that you need an NVIDIA .dll, and it tells you the location.
Another way, instead of using "Dependency Walker" is to copy all the .dll from your "C: \ Windows \ System32" folder next to your executable file. Execute your .exe and if everything loads well, so you do not have space occupied in dll libraries that you do not need or use, use the .exe program with all your options and without closing the .exe you do is erase all the .dll that you just copied next to the .exe, so if those .dll are being used by your program, the system will not let you erase, only removing those that are not necessary.
I hope this solution serves you.
Remember that if your operating system is 64 bits, the libraries will be in the System32 folder, and if your operating system is 32 bits, they will also be in the System32 folder. This happens so that there are no compatibility problems with programs that are 32 bits in a 64-bit computer.
The SysWOW64 folder contains the 32-bit files as a backup.
For a MinGW platform and if you are compiling a Debug target by a hand made CMakeLists.txt written ad hoc you need to add the qwindows.dll to the platform dir as well.
The windeployqt executable does its work well but it seems that for some strange reason the CMake build needs the release variant as well.
In summary it will be better to have both the qwindows.dll and qwindowsd.dll in your platform directory.
I did not notice the same strange result when importing the CMake project in QtCreator and then running the build procedure.
Compiling on the command line the CMake project seems to trigger the qwindows.dll dependency either if the correct one for the Debug target is set in place (qwindowsd.dll)
Use this batch file: RunWithQt.bat
#echo off
set QTDIR=C:\Qt\Qt5.1.1\5.1.1\msvc2012\bin
set QT_QPA_PLATFORM_PLUGIN_PATH=%QTDIR%\plugins\platforms\
start %1
to use it, drag your gui.exe file and drop it on the RunWithQt.bat in explorer,
or call RunWithQt gui.exe from the command line
If you have Anaconda installed I recomend you to uninstall it and try installing python package from source, i fixed this problem in this way
The application qtbase/bin/windeployqt.exe deploys automatically your application. If you start a prompt with envirenmentvariables set correctly, it deploys to the current directory.
You find an example of script:
#echo off
set QTDIR=E:\QT\5110\vc2017
set INCLUDE=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\include;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\include;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\cppwinrt
set LIB=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\lib\x86;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.14393.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.14393.0\um\x86;
set LIBPATH=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\lib\x86;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0;C:\ProgramFiles (x86)\Windows Kits\10\References\10.0.17134.0;C:\Windows\Microsoft.NET\Framework\v4.0.30319;
Path=%QTDIR%\qtbase\bin;%PATH%
set VCIDEInstallDir=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\
set VCINSTALLDIR=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\
set VCToolsInstallDir=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\
set VisualStudioVersion=15.0
set VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
set VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\
set VS120COMNTOOLS=S:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
set VS150COMNTOOLS=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\
set VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\
set VS90COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\
set VSINSTALLDIR=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\
set VSSDK110Install=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VSSDK\
set VSSDK150INSTALL=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VSSDK
set WindowsLibPath=C:\Program Files (x86)\Windows Kits\10\UnionMetadata;C:\Program Files (x86)\Windows Kits\10\References
set WindowsSdkBinPath=C:\Program Files (x86)\Windows Kits\10\bin\
set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
set WindowsSDKLibVersion=10.0.14393.0\
set WindowsSdkVerBinPath=C:\Program Files (x86)\Windows Kits\10\bin\10.0.14393.0\
set WindowsSDKVersion=10.0.14393.0\
set WindowsSDK_ExecutablePath_x64=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\
set WindowsSDK_ExecutablePath_x86=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\
mkdir C:\VCProjects\Application\Build\VS2017_QT5_11_32-Release\setup
cd C:\VCProjects\Application\Build\VS2017_QT5_11_32-Release\setup
copy /Y ..\Release\application.exe .
windeployqt application.exe
pause
Lets say, you wanted to have some CGAL-Demos portable. So you'd have a folder "CGAL", and in it, 1 subfolder called "lib": all (common) support-dlls for any programs in the CGAL-folder go here. In our example, this would be the Dll-Download: simply unzip into the "lib" directory. The further you scroll down on the demos-page, the more impressive the content. In my case, the polyhedron-demo seemed about right. If this runs on my 10+ yo notebook, I'm impressed. So I created a folder "demo" in the "CGAL"-directory, alongside "lib".
Now create a .cmd-file in that folder. I named mine "Polyhedron.cmd". So we have a directory structure like this:
CGAL - the bag for all the goodies
lib - all libraries for all CGAL-packages
demo - all the demos I'm interested in
[...] - certainly some other collections, several apps per folder...
Polyhedron.cmd - and a little script for every Qt-exe to make it truly portable.
In this little example, "Polyhedron.cmd" contains the following text:
#echo off
set "me=%~dp0"
set PATH=%me%lib
set "QT_PLUGIN_PATH=%me%lib\plugins"
start /b "CGAL Polyhedron Demo" "%me%demo\polyhedron\polyhedron_3.exe"
All scripts can be the same apart from the last line, obviously. The only caveat is: the "DOS-Window" stays open for as long as you use the actual program. Close the shell-window, and you kill the *.exe as well. Whereever you copy the "CGAL"-folder, as the weird "%~dp0"-wriggle represents the full path to the *.cmd-file that we started, with trailing "\". So "%me%lib" is always the full path to the actual library ("CGAL\lib" in my case). The next 2 lines tell Qt where its "runtime" files are. This will be at least the file "qwindows.dll" for Windows-Qt programs plus any number of *.dlls. If I remember rightly, the Dll-library (at least when I downloaded it) had a little "bug" since it contains the "platforms"-directory with qwindows.dll in it. So when you open the lib directory, you need to create a folder "plugins" next to "platforms", and then move into "plugins". If a Qt-app, any Qt-app, doesn't find "qwindows.dll", it cannot find "windows". And it expects it in a directory named "platforms" in the "plugins" directory, which it has to get told by the OS its running on...and if the "QT_PLUGIN_PATH" is not exactly pointing to all the helper-dlls you need, some Qt-programs will still run with no probs. And some complain about missing *.dlls you've never heard off...
I ran into the same error and solved it with a different method than those mentioned in other posts. Hopefully this will help future readers.
BUILD:
Windows 10 (64bit)
Minicoda (using python 3.9.4) (pkgs are from conda-forge channel)
pyqt 5.12.3
My scenario:
I was building a GUI application for some embedded work. I had two machines that were used for development (same OS and architecture), one had zero internet connection. After packaging up my environment and installing on the offline machine, I ran into the error that you got.
Solution:
locate the qt.conf file in your conda environment.
for me: C:\Users\"name"\miniconda3\envs\"env_name"\qt.conf
Make sure the paths are correct. I needed to update the "name" as this was left over from the old machine.
Hopefully this helps someone.
I had the same problem of running a QT5 application in windows 10 ( VS2019).
My error was
..\Debug\Qt5Cored.dll
Module: 5.14.1
File: kernel\qguiapplication.cpp
Line: 1249
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Solution
Since I was using QT msvc2017, I copied plugins folders from "C:\Qt\Qt5.14.1\5.14.1\msvc2017\plugins" location to the binary location
it worked.
Then check visual studio output window and identify the dlls loaded from plugin folder and removed unwanted dlls
Setting QT_PLUGIN_PATH env variable to <...>/plugins directory also worked for me.
I got the error when Pycharm was trying to run Matplot. The solution that worked for me was setting the Anaconda3\Library\plugins directory (for example: c:\Program files\Anaconda3\Library\plugins) as environment variable "QT_PLUGIN_PATH".
To set that you should go to Control Panel / System / Advanced System Settings / Environment Variables.
Talking mainly about the Windows platform
Faced the same issue when trying to debug the app build using the vcpkg installed Qt library, while having my app build using cmake. Had trouble for some hours until found the solution. The simplest way is to do the following:
in your build folder, find the folder where the final executable is located.
in that folder, you'll find some Qt libraries, like Qt6Core.dll.
pay attention to whether or not the library file has the d suffix in its name, i.e. Qt6Cored.dll instead of Qt6Core.dll
in the vcpkg folder, you have 2 options
./installed/x64-windows/Qt6/plugins/platforms
./installed/x64-windows/debug/Qt6/plugins/platforms
if the d suffix was present, copy the content of the ../debug/.. folder (otherwise the other one) into the platforms folder in the same folder, where your executable and the Qt libraries are located (if there's no such folder, create on your own).
You can somehow automate this process. Leaving that task to you. If I do that on my own, will update the answer.
Edit
If you are using CMakeLists you may want to give this a try. Add the following to your app's CMakeLists.txt
# assuming your target's name is app
if(WIN32)
add_custom_command(
TARGET app POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
${Qt6_DIR}/../../$<$<CONFIG:Debug>:debug/>Qt6/plugins/platforms/
$<TARGET_FILE_DIR:app>/platforms/
)
endif()
I have downloaded c++ open source application which was created using under Linux IDE/Editor (or maybe something NOT Windows) and its no longer supported.
This time I want to edit and recompile it using VS 2010.
Error(s) left (mostly prefixed with "wx") such as:
"wxString is undefined"
"wxStaticText expected a type specifier"
etc... makes me think that this is all about wxWidgets.
After successfully building wxWidgets, what to do next to integrate it to the actual c++ program for me to be able to edit and compile using VS 2010?
I use BorlandC++ last 2 years ago but not familiar with GUI packages.
The first step is to tell the compiler where to look for the wxWidgets include files.
So, you need to find out where these files are, which depends on where you installed and built wxWidgets.
On my system, this is C:\Program Files (x86)\wxWidgets-2.8.12
I consider the best way is to, instead of hard-coding the path in every project, create an environment variable WXROOT to store the path to your wxWidgets folder.
Control Panel | System | Advanced | Environment variables
Now you have to tell the compiler about this
Visual Studio | Project | Properties | C/C++ | Additional Include Directories
What you add here depends on what kind of build you are doing. If you are doing a unicode release build, then this will be a good start
"$(WXROOT)\lib\vc_lib\mswu";"$(WXROOT)\include"
Now you should have fixed your compiler errors.
Next you will get some linker errors ....
Maybe the errors are caused because you are using wxwidget 2.8 which is unsupported in VS 2010.
Try building wxwidgets 2.9 or use VS 2008. I had no problem building wxwidgets 2.9 on VS 2010.
Wxwidgets site home says "While this is still officially a development release because some API details are still not frozen, we believe that 2.9.3 can be used in production environment".
About what to do after successfully build it, take a look at this http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide
You may want to use the tutorial of the section "Creating a new project from a sample" 'cause creating a project by hand is a little bit complicated as wxwidgets requires some extra configuration and not just to set and include and libs dir as most of the libs does.
Here is a video which shows how to start with Visual Studio.
Also you can take a look at samples directory and create your own project based on configuration of projects from that directory.
May be I am little bit late , But this will help newcomers to wxwidgets.
First of all Goto Wxwidgets directory(to download path) in my case it is "C:\Users\WxWidgets_all".
Now in that folder goto build directory.Now open Visual Studio Command prompt. If you have already installed Visual Studio then you can easily find it through start menu.
Now in command prompt go upto <Path to your wxWidgets>/build/msw/ . Now run Following Commands.
nmake /f makefile.vc--For Static Library and Debug Version
nmake /f makefile.vc SHARED=1--For SHARED Library and Debug Version
nmake /f makefile.vc BUILD=release--For SHARED Library and Release Version
After completing it , you will have dll or lib in "<path to wxwidgets>\lib\" depending on option provided in above commands.
Now include all files related to wxwidgets in your project.Mainly two paths are required to include "<path to wxwidgets>\inlcude\" and "<path to wxwidgets>\lib\vc_<lib\dll>".
After that link your wxwidgets generated library to your project.To do this inlcude "<path to wxwidgets>\lib\vc_<lib\dll>" to your project property in library section.
Now add below preprocessors to your project.
_WINDOWS
NDEBUG(For Release)
_DEBUG(For Debug)
_CRT_SECURE_NO_DEPRECATE=1
_CRT_NON_CONFORMING_SWPRINTFS=1
_SCL_SECURE_NO_WARNINGS=1
__WXMSW__
_UNICODE
After that add following library to your project from "<path to wxwidgets>\lib\vc_<lib\dll>"
wxbase30u_net
wxmsw30u_core
wxbase30u
wxtiff
wxjpeg
wxpng
wxzlib
wxregexu
wxexpat
wxmsw30u_adv
Based on your compiled options , library name can be little bit different.
I think I have covered all the steps to run wxWidgets.
Even if you got errors , You can check minimal project in "<path to wxwidgets>\samples"
directory. Try to run that project , and even if you got error then your wxwidgets is not built properly.
Hope this will help.
I downloaded cpptest from internet, and I want to build it using Visual Studio 2008.
The problem is that instead of .sln and vcproj file, Makefile.am is distributed, and I believe that all the all the necessary included file is included in the Makefile.am.
How to use Makefile.am to generate VS project files? I tried to use Cmake, but there is no CMakeList in the distribution.
Edit: Thanks to all the answers! There is a sln file distributed after all. But I am still interested to know the answer to my original question.
the visual studio project files for cpptest are in the win directory, not in the src directory where the makefile is..
edit
makefiles are meant to be used with GNU make. If you want that on windows, you can look at Mingw, GnuWin32 or Cygwin. But they also require gcc for compiling, so you won't really be using VS.
However, for most projects that do not have external dependencies it's no big deal if you do not have the VS project file: after all a makefile is just a list of the source files and some compilation options. To successfully build projects like cpptest, you could just create an emtpy VS project, add all source files to it, set output type to executable, build it and you're done. Eventually you can tune optimization options, but for the rest the default options will just do fine.
Go to win\VisualStudio.NET and you will find a VS solution file.
I just downloaded the archive and found the .sln file. It is under: /win/VisualStudio.NET. You can open that with VS2008 and update it, it should work.
I'm working on a little game called freegemas, it's an open source version of the classic Bejeweled written in C++ and using gosu as the graphic API. I've been developing it under Ubuntu Linux as usual, but the other day I wanted to give it a try and I compiled it on Windows using Visual Studio 2005 (which I had never used before). The program worked flawlessly.
To compile it on Windows I manually copied all the source and header files to a new project on MSVC, but I would like to adapt the SVN so I don't have to recreate the project every time I want to compile it.
Therefore, the question would be: What's the best way of organizing the svn so I can have, on the one hand, a Makefile to compile the project in Linux, and, on the other side, the MSVC project's files? Right now I've got a simple folder called trunk with all header, source and resource files on it.
I've never used Visual Studio before, so I don't know which files are the most important either. Maybe some of those files are auto-generated and do not need to be svn-versioned.
Thanks in advance.
You could just keep the project files in a seperate directory "winbuild" or similar. Still, to maintain them would require manual interaction (ie adding every new file manually). The only files you would need to upload to svn are the *.vcproj (for MSVC 2005/2008) and *.vcxproj (MSVC 2010).
Alternatively, you could opt for a cross-platform solution like CMake, which could generate makefiles and Visual Studio project files from a common CMakeLists.txt, which is the only "project file" that would have to be maintained (instead of your makefile). Especially for a simple (?) project like yours (some headers+sources). There would be no need to include any makefiles or vcproj files at all, just the CMakelists.txt file would suffice.
There are others like CMake (SCons, boost.jam, jam, premake, etc.)
It should be feasable, but requires some testing and trial-and-error.