Our Qt 4.5 project has a root .pro file that has a SUBDIRS qmake variable. When qmake is called on this root .pro file, it generates a Makefile that calls "qmake && make" for each sub directory.
Now the problem is that for 100+ sub folders, this takes a long time for a one liner change of an other wise up to date project to be detected. (It takes about 13 seconds, waaay to long.) Running make at the root of the project first changes directory to all the sub dirs and runs a do nothing make, until it finds the one directory it actually needs to do work in. (A work around at the moment is to manually cd into the folder that you know you made a code change in, and just run make. For our eclipse environment, this is to clumsy.)
Ideally only the root .pro file should be tweaked, but I will accept answers that hacks the root Makefile as well.
Any suggestions to reduce the trivial make time would be appreciated.
This is a classic argument for the recursive make considered harmful theory: Your problem is that you have dozens of single Makefiles instead of one large one. The only way around the predicament is to refactor the .pro files so that only a single Makefile is generated. I don't know enough about qmake to tell you how to do that, though, sorry.
Related
I'm coding on CLion and made this log in function. The tests are being made through the .exe because CLion's Terminal sometimes jacks up the I/O's. The problem is my .exe is not finding the files I'm specifying. It runs properly through the CLion terminal, but when shifting to the .exe it doesn't.
I've read that putting those files in the cmake-build-debug/ directory fixes the issue - and it does. Thing is, this is a group project, and by putting those files in that directory I'll constantly run into compatibility troubles when pulling from git - .cmake-build-debug would have to be pushed, thus i'd have to reload it every time. This doesn't seem very proper to me.
The other option is to put the .exe file and required .dll's in the main directory. Again, would have to update this file every single time i build the project, which also isn't a very practical solution.
So I'm asking for some help regarding what can I do to ensure my .exe searches for files in the main directory, not just on the cmake-build-debug directory. The directories are included in CMakeLists, and the .exe still doesn't find them. This is quite the issue. The project will also include some rudimental form of database, so file handling will be important. Would be nice to be able to code and build without having to manually change stuff around every single time.
How do I get qmake to include the stxxl.mk file into the generated makefiles?
I have a Qt project, which deals with large files (>RAM) and therefore want to employ STXXL. The STXXL documentation says:
Building an Application
After compiling the library, some Makefile variables are written to stxxl.mk [...] in your
STXXL_ROOT directory. This file should be included from your application's Makefile.
Of course I can edit the makefile by hand to add the line include /path/to/stxxl.mk but it is very tedious to do this everytime the .pro file and hence the makefiles change.
I already searched for some solutions with qmake commands in the .pro file, but to no avail. In one forum they suggested to edit the qmake source and recompile it, but this is no choice if the program will be distributed to others, who do not have this "fix" in their qmake.
Maybe I am thinking to complicated and there is a simple solution. I hope there are some people here who did solve this problem, when working with this combination (Qt + STXXL).
Note
This question Prepend/Append Makefile to a Qt generated Makefile was asking for quite the same but the solution does not fit to my problem.
For now I have settled with the following solution:
As the stxxl.mk file contains "valid qmake code" (it assigns to variables), I use include(stxxl.mk) to import these variables. So my resulting project file contains:
include(/path/to/stxxl.mk)
QMAKE_CXXFLAGS += $$STXXL_CPPFLAGS_STXXL
LIBS += $$STXXL_LDLIBS_STXXL
These were the only variables of stxxl.mk that were used in the documentation so I used them and it works.
I've searched this for a while and haven't found anything answered anywhere:
I have a project in QtCreator that has no compilation errors, and runs fine as a normal C++ project in Eclipse.
However, when I try to run it as a Qt app, it says it could not find an executable and I need to specify one.
As many other sites have suggested, I have searched the directories for the .exe that QtCreator was supposed to make (according to the other sites), but I am yet to find anything.
I'm in no rush, but have spent a long time on this and would like to move on to actually writing the Qt part.
Thanks in advance.
Are you still struggling with the solution ? The most easy solution is, restore default setting by deleting file QtCreator.ini. After that configure project once again by giving build directory path. If you are working on Linux system, run following command to find QtCreator.ini file.
$ locate QtCreator.ini
It will give ouput like this
/home/tan/.config/QtProject/QtCreator.ini
Then delete the file on obtained path using following command
$ sudo rm -f /home/tan/.config/QtProject/QtCreator.ini
Now open project once again and configure with your desired build and run settings.
Upvote if above solution helps you. Btw if I've made any grammatical mistakes, I am sorry for my english. :)
Best luck !!
I'm not sure I understand what you mean by having a QtCreator project and running it in Eclipse or running it as a Qt App but if you are looking for an exe file, QtCreator is probably configured to do shadow builds for your project. This means that build output is sent to a directory outside of your project source directory. If your project is in a directory called MyApp, then look for a directory beside it called MyApp-build-desktop. You should find your executable in there.
I'm trying to execute the qmake -project command by doing:
C:\Qt\2010.05\qt>qmake -project
But, it remains there and doesn't get executed. Why is that?
Thanks.
qmake -project without any additional arguments will traverse the current directory recursively, looking for e.g. source, header and UI files to be included in the .pro file. When you run it in a directory containing lots of files (such as Qt folder), it can take a lot of time to go through all of them. Thats why it seems to get stuck.
I'm making changes to a form in Creator but when I build the changes are not being "refreshed".
I've gone so far as to remove every element from the form and get rid of every stylesheet but when I build the project I get the same result; as if I had never made a change at all.
What gives? Am I missing something obvious? (obvious to everyone but me.. obviously)
I guess you're using QtCreator 2.0? I found the same strange issue. You have two options:
Remove the ui_{the_name_of_design}.h from the project's build dir. Then run qmake again.
make clean or Build → Rebuild All
But the second option even doesn't help with me. By the way that's why is good to use a different build dir than that where the sources are. If some changes don't appear to be applied, just delete the content of build dir, and everything goes fine as well.
Cheers
Most likely cause if that your make procedure is not noticing the changes in the .ui file, and so it is not calling the uic tool. Try to do a make clean to see if it helps, and check your build log to see if uic is being called.
For me, the solution was to change the BuildDirectory to the same directory where the code is, instead of the **-build-desktop directory.
I stumbled upon this issue as well and one thing I noticed was that my program was still running in the background without me knowing. Ending the task through task manager fixes it and you can make changes again.
A few suggestions:
Perform a make distclean.
Use a shadow build directory. Building “inside” the source code is not advised.
Check your computer’s clock and the date and time of your files.
This thread is a little dated but since I got caught up in the same problem I thought I would share how I resolved this.
I've been incrementally building up a ui with designer under QtCreator 2.4.1/Qt 4.8.1 using a poor man's source control approach: snapshots. At one point I inadvertently created a non-shadowed build project. In a subsequent snapshot I reverted the project back to shadow build and at that point new widgets added in the ui form were no longer being recognized in the build.
Solution:
Delete stale ui_.h files from the source directory.
Delete make and ui_.h files from your shadaow build directory.
Rebuild
Latest generated ui_.h files will reappear in the shadow build directory.
No copies of ui_.h files appear in the source directory indicating that the stale files were taking precedence in the build order. Not obvious.
I have this problem and i solve it by changing the project path. I had stored the project in my flash memory when i had this problem, then i copy the project folder and it's build folder also in the Desktop and open it with QtCreator and the problem was solved.
Problem is indeed stale generated files in project source directory. This can happen both with genrated ui_*.h files, as well as with moc_*.* files. Below is not covered by existing answers, so here we go:
To remove generated files from the project source directory, without affecting Qt Creator settings or current shadow build directories, there are two principal ways, which can also be combined for extra coverage.
Go to Qt command prompt, go to project source directory and run these commands:
qmake -r
make clean
make distclean
1st one will recursively create makefiles. 2nd one will remove all files produced by building the project. 3rd one will remove the makefiles again. Then continue using shadow build from Qt Creator as before.
The problem with this is, it will leave files which are not part of the project. So if some files have been removed from project, related generated files may remain, and cause trouble if files with same name are added back. So even after this it is good idea to verify no ui_* or moc_* files remain, if you know you have removed files from project.
Use your version control software to first commit or stash/shelve all uncommitted changes, and then remove all unversioned (also otherwise ignored) files. For some version control software this may not be easy as git clean -dxf (beware, that will also lose uncommited changes and Qt Creator's custom project settings), and in that case it may be easier to just remove project source directory and get a clean checkout.
The problem with this is, if some generated files have accidentally been added to project, they will not be cleaned up with this. So it may still be a good idea to do the step 1 above too.
Above steps should be in sync so that after step 1, any files in source directory (except Qt Creators's projectname.pro.user and possible *~ backup files) should be under in version control.