In some of my projects I use some pre-build step(s) configured in the .pro file. So qmake will execute this step whenever it is activated.
Now in QtCreator, when I build (also when completely rebuilding the whole project), it doesn't always run qmake, since it tries to be clever and optimize this. It only runs it when the .pro file has been changed, causing several issues.
Also a common issue is, when you make a class inheriting from QObject after running qmake on that file, it will not notice it and hence not run moc on it. Such issues are solved by simply manually running qmake via the "Build" menu in QtCreator. But if I forget this I am sometimes confused by the compile errors I get because of this and this is really annoying.
(How) can I force QtCreator to do this step always when building a project?
I thought about adding qmake as a build step in the project configuration, but this seems to be a dirty hack to solve this problem.
Another dirty hack but a little more flexible: On Linux/Mac add "touch yourprojectfile.pro" as a build step or assign an external tool call to sth. like touch "*.pro" run in your current projects working directory. When the pro file is altered (which is mimicked by touch) qmake is executed. Not much cleaner but the external tool plus hotkey solution is more flexible than adding qmake into the buildsteps of each an every project.
Update:
I finally found a completely satisfactory solution for this.
In the pro file add:
qmakeforce.target = dummy
qmakeforce.commands = rm -f Makefile ##to force rerun of qmake
qmakeforce.depends = FORCE
PRE_TARGETDEPS += $$qmakeforce.target
QMAKE_EXTRA_TARGETS += qmakeforce
This deletes the generated Makefile an thus forces qmake to rerun for every build.
I think your best option is customize your QtCreator .This can be done by write a plugin for QtCreator ,or you can change the souce code of a plugin named Qt4ProjectManager ,then build it for yourself . This might be complex ,however, can be a solution.
What I've done is created a makefile that explicitly calls qmake. Of course, that means I have two makefiles, but in my project file, I have
MAKEFILE = makefile_qt
which means that the generated makefile will have that name.
So, for the makefile I manually created, I have:
default:
qmake;
${MAKE} -f makefile_qt;
Then, from QtCreator, I just call the regular make, which will default to makefile. Or you can leave the Qt-generated makefile as is, and just call make -f makefile to call your manually created one. I forget which has precedence, makefile or Makefile, and I'm not sure if it is always the same.
I'm using the following codes in my .pro file.
QMAKE_CLEAN += ./Makefile
This makes run qmake whenever executing clean.
Related
I have a Qt project file (.pro) and a Makefile (self-written).
The project file is simply used for editing the source files in the IDE:
/home/project/
./src/fooApp.pro
TEMPLATE=app
CONFIG-=qt
TARGET=fooApp
SOURCES+=...
HEADERS+=...
./src/main.c
./src/foo.c
./src/foo.h
./build/Makefile
I would like to build the project via IDE QT Creator 3.5.1
Therefore I would like to invoke make on the Makefile.
During the build process I always get the error that no Makefile can be found hence no build was triggered.
The solution is to always invoke qmake first, then make (even if a Makefile is still present and custom setting make -C ../build in /home/project/)
Could someone please explain, why it is not possible ignore qmake and directly invoke make on the already existing Makefile?
(No Qt library is used for the project)
Regards
This is quite easy, I use makefile only project alot because I like qt-creator as an IDE. In the IDE goto the projects tab on the left.
Select the "build" tab near the top of that page, looks like: (build | run).
In the build steps:
remove the qmake build step by press hovering the mouse over that step and clicking the X that appears.
Edit the build directory so that it is the same directory as your makefile.
Note: you will have to click the shadow build check box next to it to enable it.
remove any other steps you don't want (infact just remove them all for now).
Add a new step make step. It will try to use the default make, but you can override that if you want. Also add any arguments like debug or -j4 etc...
Then you are done :)
Next time you hit build it will simply invoke that make command.
Note: You will need to do the same for any other configurations you have (like release, debug, etc...). You can also just add loads more configurations for doing other make options (if you have them) for instance make doxygen or such...
Just remembered you can also either:
I am not sure why, but when I tested it (as OP did) you can't seem to just setup a make step with parameters -C ../, it seems to want to look in the "build directory" first.
I tend to use the build location since its a nice feature of the IDE.
Note an issue with newer versions of Qtcreator as a makefile IDE is that you cant share your build settings with other people (i.e. can't configure control them) because they are locked to your PC profile... long story... but its very sad and I no longer use qt creator for that one reason.
I'm learning GNU make . Suppose I have a hello_world.c file and a Makefile:
hello_world.c:
#include <stdio.h>
int main() {
printf("Hello World!\n");
return 0;
}
Makefile:
hello: hello_world.c
gcc hello_world.c -o hello_world
Now, I think hello is my target and hello_world.c is its dependency. If make somehow detects that hello_world.c is newer than its object-file, it executes the corresponding command.
1- How does make manage file version control and how does it detect something is newer than something else and needs updating?
2- If I change hello_world.o using an editor and corrupt the file, it obviously does not execute but make hello reports that nothing needs to be done!
I mean, make only checked that the dependency is older than the target and exited doing nothing. I think it should have detected that this target is not the one corresponding to its latest invocation. Somehow, it should have compared the "combination of dependency AND target" history instead of just comparing dependency's history w.r.t. target.
3- Is this the limitation of make? How can I circumvent this issue? Because there maybe some external apps messing with the target of my make operation.
1- How does make manage file version control and how does it detect something is newer than something else and needs updating?
You already know the answer to this question. You said it in your next paragraph: "I mean, make only checked that the dependency is older than the target and exited doing nothing." That's right. make updates dependent targets when the dependencies of targets are newer.
2- If I change hello_world.o using an editor and corrupt the file, it obviously does not execute but make hello reports that nothing needs to be done! I mean, make only checked that the dependency is older than the target and exited doing nothing. I think it should have detected that this target is not the one corresponding to its latest invocation. Somehow, it should have compared the "combination of dependency AND target" history instead of just comparing dependency's history w.r.t. target.
You are asking make to do a lot more than what it was intended to do.
3- Is this the limitation of make? How can I circumvent this issue? Because there maybe some external apps messing with the target of my make operation.
From your point of view, it does seem like it is a limitation of make. However, I want to point out that you are sabotaging the workings of make by updating a target manually.
How can you circumvent it?
Don't manually modify targets that are built by make.
Manually update the time stamp of one of the dependencies and then run make. You can use the command touch for that.
Provide a dummy target named clean that will remove all the dependent targets. Then, run make clean followed by make.
Provide a dummy target named rebuild. Forcefully build whatever you need to build in that target. Then, run make rebuild.
The make program simply compare the modification time-stamps of the target (hello) and the dependency (hello_world.c) files.
If the time-stamp of a dependency file is newer than the targets, then it execute the commands.
How does make manage file version control and how does it detect something is newer than something else and needs updating?
Very simple: make does not care about file versions.
Detecting if something is newer than something else is simply done by comparing time stamps from file system.
If I change hello_world.o using an editor and corrupt the file, it obviously does not execute but make hello reports that nothing needs to be done! I mean, make only checked that the dependency is older than the target and exited doing nothing. I think it should have detected that this target is not the one corresponding to its latest invocation. Somehow, it should have compared the "combination of dependency AND target" history instead of just comparing dependency's history w.r.t. target.
You did not tell make anything about your .o file. Why should make check the timestamp of that file?
Checking the dependency is exactly what make is expected to do.
How should this tool possibly know that a file calles hello_world.o is involved in the process if you don't tell it? There is no magic happening but only the rules of your Makefile are followed.
Is this the limitation of make? How can I circumvent this issue? Because there maybe some external apps messing with the target of my make operation.
You can specify hierarchical dependencies:
all: hello
hello: hello_world.o
<gcc linker command...>
hello_world.o: hello_world.c
gcc hello_world.c -o hello_world
I have a project which uses Makefiles. On a branch, I have CMake based build system. Now some team-members wants the OLD make-files based system intact, when cmake is added. But this is not possible after cmake . command overwrites the old Makefile.
Now I can easily avoid it if I can tell CMake to generate makefiles with some non-standard names e.g. makefile.cmake etc. Is it possible?
I am open to consider other options as well. In any case, old Makefiles must not be touched.
Cmake creates a build system in the working directory. So create any empty directory, and run cmake <path-to-source> from there.
Unfortunately, the name "Makefile" in hard-coded several times, in the sources of CMake. You cannot change it. As Peter has pointed out in the other answer, that change is not necessary, because CMake support out-of-source builds.
I am currently working on a project on a student job and writing some code. Whenever I want to compile my file, my supervisor told me to first do gmake clean and then do gmake. Otherwise,some errors from previous gmake may not be solved in the fresh gmake.
My project has a lot of unnecessary files that I am not editing but since i gmake clean everytime, the compiler compiles them again everytime which takes a lot of time.
So, if I am not changing the other files, then I don't need to recompile them and the only file that I change is always recompiled simply with gmake, right? So why should I gmake clean everytime?
Is my supervisor just telling me a good programming practice or am I missing some important concept of gmake clean?
The difference between gmake and gmake clean is that the former builds the default target while the latter "builds" the specific target clean, which usually consists of clean-up instructions to remove files that were created during the build process (object files, temporary files, generated code, …). gmake clean should restore the source tree to a clean state. However, if it actually succeeds depends on how the source tree looks like and what instructions the target contains.
definitely not a best practice... this is usually the quick and dirty solution when the makefile contains a few mistakes and the dependencies are not ok
do gmake clean before gmake in case you have difficulties to compile. just to check if the problem does not come from an old compiled file.
otherise do only gmake in orther to compile your newest changed files.
you superior gived you an advice to handle difficult and strange compilation behavior.
I develop C/C++ using the Eclipse IDE. Eclipse also generates a makefile which I don't want to edit as it will simply be overwritten.
I want to use that makefile for nightly build within Hudson.
How do I pass #defines which are made in the project file of the IDE to the makefile ? (and why doesn't Eclipse already include them in the generated makefile?)
I actually had this figured out once, then accidentally overwrote it :-( But at least I know that it can be done...
If you are running make from the command line, use
make CPPFLAGS=-DFOO
which will add -DFOO to all compilations. See also CFLAGS, CXXFLAGS, LDFLAGS in the make manual.
You could write a small program to include the headers and write a makefile fragment which you include in the main makefile (requires GNU make).
This is a fairly ugly solution that requires a fair amount of hand hackery. More elegant would be to parse the project file and write the makefile fragment.
For GCC use -D define.
OP commented below that he wants to pass the define into make and have it pass it on to GCC.
Make does not allow this. Typically you just add another make rule to add defines. For instance 'make release' vs 'make debug'. As the makefile creator you make the two rules and have the defines right in the make file. Now if Eclipse is not putting the defines into the makefile for you, I would say Eclipse is broken.
If you're using autotools another options is to have 2 directories 'bin/debug' and 'bin/release'.
# Simple bootstrap script.
# Remove previously generated filed and call autoreconf.
# At the end configure 2 separate builds.
echo "Setting up Debug configuration: bin/debug"
../../configure CXXFLAGS="-g3 -O0 -DDEBUG=1"
echo "Setting up Release configuration: bin/release"
cd bin/release/
../../configure CXXFLAGS="-O2"
Setup Eclipse. Open the project's properties (Project->Properties->C/C++ Build->Builder Settings) and set the Build Location->Build Directory to
${workspace_loc:/helloworld/bin/debug}
Replacing 'helloworld' with your project's directory relative to the workspace (or you can supply an absolute path ${/abs/path/debug}). Do the same thing with the Release config, replacing "/debug" with "release" at the end of the path.
This method seems like a waste of disk space, but a valid alternative to achieve completely separate builds.