The PC I'm using has 4 cores so I wanna use all them while compiling, which I do by passing the -j4 option to the compiler. In Qt Creator I do that by adding an environment variable in the Build Environment panel, as shown in the images:
MAKEFLAGS = -j4
The problem is that this setting doesn't persist across all projects in the PC I'm using, which will be cool. So I have to do that for each project at least once. I think this is stored in the .pro.user file, since every time .pro.user gets deleted the MAKEFLAGS = -j4 desapears from the Build Environment panel.
Isn't possible to just add this setting via .pro project file?
I'm interested in any approach which will allow me to escape from the necessity of setting that stuff multiple times.
To give a little context, I'm on Windows.
You're looking for shared project settings in a .pro.shared file. They are designed exactly for what you have in mind.
Adding the setting to a .pro file is wrong, since that file is meant to be portable and not tied to any particular build host.
Related
I am trying to populate a QTableview with some data. When developing under Qt Creator, data is read from build directory. Running the program each time, the QTableview keeps getting repopulated with previous data.
If I manually change the build directory each time before run, doesn't happen. But how do I solve the problem without manually changing the build directory every time I want a fresh run?
In your project directory there is a file name ProjectName.pro.user.
This file creating when you configure your project. it's XML file.
you can find this line on *.user files:
<value type="QString" key="ProjectExplorer.BuildConfiguration.BuildDirectory">C:/Users/probook/Documents/Qt/testProject/Build/Windows/Debug</value>
This line define build directory address for debug. there is a same line for Release and Profile in that file.
You can also use Qt creator to define(customize) relative directory build:
goto Qt creator, Tools, Options..., Build & Run, General, Default build directory.
More info:
Qt Creator stores user-specific project settings in a .pro.user file. You can share these settings between several projects as a .pro.shared file. It has the same XML structure as a .pro.user file, but only contains the settings to share.
Based on comment, issue seems to be data which gets saved to build directory. And solution would be to remove it before running the application.
You can add Custom Process Step, either under Projects - Build Settings -
Build Steps, or under Projects - Run Settings - Deployment, and just delete the desired data files. Exact command depends on operating system.
An alternative might be to add a command line switch, something like --development-erase-saved-data, to the application itself, and erase the files (or just not read them, or whatever). Then add that command line switch to Projects - Run Settings - Run Steps - Command Line Arguments for desired build configurations.
Adding support for this in the application itself is easier to maintain, and is almost automatically cross-platform. However, it might be a feature you don't want in the application, though in that case you might only enable it for Debug builds (with #ifdef).
As a side note, saving data to executable directory is not a good idea these days. You might want to save it for example to location returned by
QStandardPaths::writableLocation(QStandardPaths::AppDataLocation)
(See here for more info.)
Every single time I change something in a Qt .pro file (add a new source file, change compile flags, etc...), my changes do not take effect. I am using Qt Creator. The same thing happens on windows (MSVC compiler) and Mac. If i remove build directory, it's ok then. (not counting wasted time for full rebuild)
Could be a bug but as it sounds so trivial it rather feels like I am missing something.
Thanks!
When you change somethng in a *.pro file, you have to re-run qmake on the project, to refresh the files in Qt Creator. You don't need to delete your build folder every time.
But when you delete the build folder, Qt automatically run qmake on the project before running the compilation. Your solution works, but it's a bit overkill ;)
This menu is also available when right-clicking on the project
To test the deployment process I am trying to deploy the included demo app Minehunt. I am able to get it to run, no crashing or errors, but the screen is all white.
I believe this generally means that I am missing plugins. Dependency walker reports no problems, and I even tried including ALL the plugins from the Qt MingW plugins directory, but no such luck.
Here is what I am including so far; Can anyone advise what else I need to add to get it to run?
Your dlls don't look bad at all. I think, too, that it's your plugins. Even if they are there, there is a good chance, that your program don't find them. Qt is a bit picky where to look by default. You might try qt.conf. This is a small textfile you must create in the folder where your executable lies. It contains the path to your Qt plugins.
For instance, in one of my projects I have the followin folder layout:
Appfolder
plugin
qt
plugins
imageformats
sqldrivers
myapp.exe
qt.conf
...many dlls...
Then I added a qt.conf file to the Appfolder, which has the following content:
[Paths]
Plugins = plugins/qt/plugins
My program is Qt 4, but I don't think this aspect of plugin deployment changed in Qt5.
All my qt dlls are in qt. And I add the following PATH: SET PATH=.\plugins;.\plugins\qt;%PATH%. Works like a charm on any Windows I ever tried.
Edit:
I then created a .bat file, which does:
SET PATH=.\plugins;.\plugins\qt;%PATH%
cd Appfolder
start myapp
This was an ugly quick fix, which I did not have the time to replace with something better, yet.
If application runs and shows blank screen then that usually indicates two things :
All the dependencies (dlls) are probably present and detected properly.
Most probably whats missing is the presence of qml files at the correct location.
In your main.cpp check the path of qml file which you would have given, and see if relatively that folder is present at the same location corresponding to your executable.
Also, instead of running the executable by double clicking, run it through the command line. It might print some messages if it is not able to locate some images/files/other dependencies etc according to the specified paths.
Edit 1 :
Add this flag in the .pro file :
CONFIG += console
It will give the exact debug message in a console once you run the application.
I can see from the documentation on https://qt-project.org/doc/qtcreator-2.6/creator-sharing-project-settings.html how to create a .pro.shared file that standardizes Editor settings.
But there's no mention of build configurations, build steps, deployment methods, or run configurations.
I tried just renaming my .pro.user file (which includes custom build, deployment, and run configuration) to .pro.shared, but when I reopened the project, I got the defaults.
What's the right way to specify these settings in a .pro.shared file?
So short answer: You can't. Those settings are the reason why it is a .user file: They reference settings that are specific to one Qt Creator instance.
Long answer: We are moving to support this use case better, 2.6 was a huge step in that direction. With 2.6 you might be able to share build/deploy/run settings, but you need to make sure everybody using that .user file has compatible kits with exactly the same ids. You also need to make sure that everybody is using the same paths to sources, builds, operating system, etc. which limits its use quite a bit.
This might work e.g. with the Qt 5 kit installed by the official Qt 5 packages or with kits created specially for your setup. This will fail in any setup where you do not have tight control over all the development setups! On the other hand: If somebody is using a non-default setup of creator (kits, paths, etc.) then creator will just throw away some or all kit defined in the .user file of the project and will then continue, asking for kits to use. That is exactly what you will get without a .shared/.user file available at all.
Please be aware that as far as I know nobody ever tested such a setup. So you will most likely run into bugs and misbehavior... if you do: Please file bug reports at https://bugreports.qt.io/ ;-)
If you have only one environment you are targeting with your development, then you can get pretty far by having that environment set up (e.g. you only have one compiler/Qt version/kit defined that is exactly what you want everybody to use). Creator will then just default to that one, even if you have no .user file at all.
I'm trying to deploy an application using macdeployqt. All Qt frameworks get copied correctly into the application bundle. The problem I encounter is that macdeployqt does not have write permissions on the copied frameworks which originally reside in /usr/local/lib. This is because I have installed qt using homebrew which seems to make install everything read only. My question is whether there is a better way to fix this issue then manually changing all permissions of the qt libraries inside /usr/local/lib so that I can use macdeployqt from within a qt .pro project. (I don't want to use macdeployqt manually with sudo or such)
The reason why I'm asking is because I am using many third party libraries in the project (they get copied ok etc.) which I need to update often through homebrew and thus have to redo the permission changing on them.
Thanks in advance!
Just in case someone finds this old post looking for info about macdeployqt:
Use a script to do macdeployqt in preference to scripting the macdeployqt commands in your .pro file. That will allow you to change the permissions on the files on the fly.
Here is [a snippet of] the script I use for one of my apps:
https://bugreports.qt-project.org/browse/QTBUG-23268
If you're on Windows and don't have bash, you can use perl or python. The script referenced above modifies the files on the fly to work around a bug - you can put anything you want here, including changing the permissions on the files.
Using a script also means that you have the flexibility to add commands later to do code-signing, packaging or whatever else you need.
The Qt .pro "scripting language" actually generates Makefile commands under the hood and can be quite obscure if you want to accomplish deployment tasks that relate to paths and sets of files.
Also you'll need to create an extra target or include it into your build target - either way the build process becomes more complex and more error prone.
Disclaimer: I worked on Qt for 8 years as a Senior Engineer for Nokia/Trolltech, and also have published a commercial cross-platform app using Qt.