I'm building some custom Qt components as a static library, but I can't get past the compilation phase.
My project is structured as follows:
Root:
- .h and . cpp files of the custom Qt components
- GeneratedFiles/Debug/ <-- here the MOC compiler puts the generated moc_*.cpp files ("Debug" is automatically deducted from the build configuration, so it's Release for release builds)
That's a pretty standard folder setup, but for whatever reason the compiler can't find only the moc files. Anything that is in the root folder builds just fine, but the moc files are not found. Please note, the moc_ files are generated just fine and exist where they're supposed to be, with the correct content. The problem seems to be in the evaluation of the path GeneratedFiles\Debug\moc_whatever.cpp.
Interestingly enough, if I move a moc file (say, moc_example.cpp) in the root folder and manually adapt the call to CL.exe to compile moc_example.cpp instead of GeneratedFiles\Debug\moc_example.cpp, the file gets built.
I'm using VS 2017 version 15.7.1, CL is version 19.00.24215.1 for x64 and I'll update the question with any other detail might be useful, just add ask in a comment.
So... Why is the compiler telling me those files do not exist?
I finally solved this rebuilding the directory structure in a new directory. Apparently, using WSL's git to check out repositories under Windows breaks something in the filesystem in a way that is invisible from Explorer or Ubuntu's command line, but that breaks the compiler (and Visual Studio's intellisense).
Checking out the repository with Git for Windows seems to avoid causing the same problem.
Related
Intro
I have a CMake-based C++ project. Until now I build and ran the project via CLion. Everything worked fine until I tried to run the .exe-file directly (not via CLion).
Problem
When I navigate to the cmake build directory in order to start my program via the executable file, it fails with the following message in the popup: Cannot continue the code execution because libgcc_s so-1.dll was not found. Reinstalling the program may resolve the issue.
I have the following questions
If I interpret the error message correctly, then this dll is missing on my computer. So I ask myself, why does my program still work when I start it via the development environment (CLion), although the error message expressly states that the source code requires this dll?
Is it the fault of my application/source code that the error appears or rather the current state of my computer? If the former, how can I prevent this error from appearing for other users?
What is the best way to fix this error? It's obvious that I need to download this dll, but where is the best place to put it (which directory and environment variable to use on Window)?
Which source is trustworthy to download this dll? I don't want to download any malware under this dll-name.
Optional: What kind of library is that? What functionalities does it offer?
Additional information
I use CMake as my build tool, CLion as the IDE and MinGW as the compiler.
What I have did so far?
I made sure it still works through the IDE.
I found this dll does not exist in the MinGW installation folder.
I searched the web for more information. Unfortunately, there are only pages unknown to me that only offer the download of this dll. That doesn't satisfy me.
I found the cause of my problem: I had two MingGW installations on my machine. Once the installation that comes with CLion and a separate one. The latter did not have the required dll. However, CLion used its own installation, which in turn owns the DLL. So the solution was to remove the separate installation and include the path to the CLion installation's bin/ directory in the PATH environment variable.
This file is part of MinGW-w64 when using SEH as exception model (as opposed to Dwarf or SJLJ). You need to distribute the .dll files your .exe file(s) depend on in the same folder as the .exe file(s).
If you don't have that file, then you probably have been using libraries compiled with different versions of GCC/MinGW(-w64). I recommend building everything with the same compiler to ensure stable binaries.
Tools like Dependency Walker can help you figure out which .dll files your .exe file depends on.
Or use the command line tool copypedeps -r from https://github.com/brechtsanders/pedeps to copy the .exe files along with it's dependencies.
I want to package my executable file and other needed files into an install file (using NSIS) so that other people can install and use. There are a few file types I am uncertain of whether they are needed for installation or if it is safe to delete them.
Here is a random example of the files in the project folder as well as the Debug file automatically generated by VS:
I have already deleted the .user file as I know that is not needed, but not sure when it comes to .vcxproj, .tlog, .build.cppclean, .idp, and .pdb files. Also, do I need to keep the .obj files as well as the .cpp files?
This is my first time trying to do this, I am just messing around to seeing how it all works so thanks in advance.
You generally only need the .exe. Your app might depend on custom .dlls or the C++ run-time library in which case you would bundle the custom .dlls and/or the C++ redistributable.
Your screen shots are of a debug build and you normally want to distribute a release build instead because it is often smaller and contains more optimized code.
.obj files contain the machine code for each source file and is used by the linker when it merges all the required code into your .exe.
.pdb files contain debugging information. You should not distribute them but it is helpful to store them for yourself in case you need to debug a released version of your application.
The rest of the files in Debug and Release can also be ignored.
If your project is open source then you could include the c/c++ files and the Visual Studio project files. Or you could just upload them to Github.
In NSIS you could do something like this
InstallDir $ProgramFiles\MyApp
Page Directory
Page InstFiles
Section
SetOutPath $InstDir
File myproject\Release\MyApp.exe
File mylibrary\Release\*.dll
SectionEnd
It is a good idea to test your installer on a freshly installed Windows instance. Ideally the minimal version you require, Windows 7 etc. This should allow you to verify that you have included all the files required by your application.
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.
I have a Qt project with QML files. Whenever I change these files, I have to manually right click the .qrc (resources) file and recompile it.
How do I tell visual studio to always compile a certain file, not only when it thinks it has changed?
(Here are similar questions others have asked for eclipse and flashdevelop)
I encountered the same problem while building qt apps using Qt Creator.(Especially while using QML files as resources.) I solved the problem using a little hack.
Created a batch file say touch.bat in my source directory.
This batch file contains a single line copy qml.qrc /B+ ,,/Y where qml.qrc is the resource file name.
Opened my project in QtCreator and went to Project->Build Steps->Add Build Step->Custom process step and entered touch.bat
Whenever the project build starts, the qml.qrc is touched. The build system thinks that qml.qrc is modified and builds it.
You can modify this hack for Visual Studio also.(I have not tried). Try adding touch.bat as a build step in Visual studio. The idea is to fool the build system to think that your .qrc is modified.
I guess this is a known bug which remains unresolved. Check this bug report.
Thanks.
I am trying to build and run Google Test but encountered some issues.
Any help greatly appreciated.
I used CMake 2.8 (with UI) to create .sln and .vcproj files in the D:/MyBuild
directory (as mentioned in the README file of google test).
However, when I try to run the .sln file in the MyBuild directory,
here is what I get (image):
Also, here is a screenshot of the CMake which I used to
create .sln files and .vcproj files in the D:/MyBuild directory.
ps. One thing I noticed is that README was giving instructions how
to use non graphical version of CMake (e.g., 2.6) to install
google test, however I used one with user interface - maybe
I did something wrong there?
You appear to have successfully built gtest's libs in Debug mode. However, by default the .sln doesn't contain any executables, so you can't actually run anything.
If you select the checkboxes in the CMake GUI for gtest_build_samples and/or gtest_build_tests and hit "Generate", then the Visual Studio solution should contain some executables.
From memory, these don't build cleanly, but I don't have MSVC 2010 to hand, so I can't be sure.