Automatically rebuild dependencies in Qt Creator - qt

Question

Qt Creator (4.6.1) is driving me nuts. My application is split into 3 parts:
the app
the library
a unit tests app
When I change a file within the library and rebuild the application, the compiler does not recompile the library but links with the old version of the library.
Also, when I change the library, recompile it and then compile the app, no compilation takes place because it uses the cached app.
Is there a setting to change that? Here's my project file:
TEMPLATE = subdirs
SUBDIRS += \
app \
lib_mylib \
tests
app.depends = lib_mylib
tests.depends = lib_mylib
The lib is built as a static library:
TEMPLATE = lib
TARGET = mylib
CONFIG += staticlib

Answer 1

I know it's a little late, but I would like to give an a little more extensive answer why this happens and how exactly the other solutions help.
A working solution will be: You use either b.depends += a as you did before or CONFIG += ordered and add PRE_TARGETDEPS += ... to b. (Side note: ordered is not recommended, as it can drastically slow down your builds and is generally considered bad practice)
TL;DR: The reason why this special combination is needed: The app.depends = lib_mylib in the subdirs project ensure that the library is always built before building the app is started, and the PRE_TARGETDEPS ensures that the app is actually beeing rebuild everytime the library changed.
Long explanation:
To understand why that works, we need to understand how qmake handles subdirs. qmake is a Makefile generator, which means it will only create makefiles. So all dependency ordering must be done using the methods make prodives. To understand what happens, we must understand how make works, first.
In make, dependencies are relatively simple:
some_target: dep1 dep2 dep3
some_command
means that if you want to create some_target, make will create dep1, dep2 and dep3 first, in an unspecified order. Once all 3 are finished, some_command is executed.
However, make will optimize this for files. Considering the following:
hello.txt:
echo "creating hello"
echo "hello" > hello.txt
hello2.txt: hello.txt
echo "creating hello2"
echo "hello2" > hello2.txt
Running make will create the both files and print both messages. Running it a second time will do nothing. The reason here is that make keeps tracks of already created files and file changes. Since hello.txt already exists, it is not created again. And since hello.txt has not changed, there is no need to create hello2.txt again. If you now externally change the contents of hello.txt and run make again, hello2.txt will be created anew and you will see the message.
Now with subdirs projects, this gets a little more complicated, as we now need dependencies between multiple different makefiles! This is typically resolved by recursive make calls. For your example, qmake creates the following code (simplified):
lib_mylib: FORCE
$(MAKE) lib_mylib/Makefile
app: lib_mylib FORCE
$(MAKE) app/Makefile
This code will, as expected, create lib_mylib first (blocking, i.e. the lib_mylib will only finish once the whole lib has been built) and after that create app. The FORCE depenency ensures that this command is always run, even if the target already exists.
With those basics in mind, we can now reconstruct what happens for qmake. Using the b.depends += a will generate code as above - it makes shure that all dependencies are built in the correct order, but nothing else! Using the ordered config will simply automatically create those depends rules, so there is no logical difference in how they work.
However, this is not enough to actually rebuild app when lib_mylib changes. It only ensures that lib_mylib is built before make starts building app.
In order to rebuild app, we use the PRE_TARGETDEPS - this adds a dependency as shown before to the make target in the apps makefile
app.exe: mylib.lib:
#linker code
This means that every time lib_mylib changes, app is now rebuilt as well. Using this without the ordered config however can fail, as it is possible that make would first try to build app (which either does nothing, as lib has not changed, or will fail if lib does not already exists) and after that rebuild lib_mylib. Running make a second time will the rebuild app as well - but thats rather inconvenient.
So, thats why we need to combine those two. We need to control the order in which the different makefiles are executed and references the created artifacts from the other makefile - and thats exactly what those commands do.

Answer 2

I have used CONFIG += ordered, DEPENDPATH and PRE_TARGETDEPS to get rid of the same problems. It works for me on linux and on win with MSVC. Try it.
in your project pro file add:
CONFIG += ordered
P.S.: your lib should be listed first. Like :
SUBDIRS += \
lib \
app \
tests
in your exe .pro file add this with correct paths:
DEPENDPATH += $$PWD/../lib
PRE_TARGETDEPS += $$OUT_PWD/../lib/liblib.a
More options and flags is to be found here

Answer 3

Regardless the long and understandable explanation I've tried with
TEMPLATE = subdirs
CONFIG += ordered
SUBDIRS += \
dynamiclib \
staticlib \
testlibs
for my rather small and short project and it worked for me.