[Solved] Change of library but creator does not build completely

[koahnig]

I have several static libraries and an application and I am working with Qt creator. In the beginning I had subdirs template for the whole thing. Problem was that not every time the library and the application was be compiled.
Recently I have changed so that every lib has its project and the application too. For the application I have defined that it is dependent on the different libraries involved.
I still have the same problem as before. I am using ctrl+shift+s to store all changes (even so only one file has changed). Afterwards I am pressing ctrl+shift+b to build all. My assumption is that the changed file of the library will be compiled and stored in the library. Afterwards it should start the linking of the application with the new library, but it does not.
I had run qmake for the static library and also the application. Nothing changed.

Is the only chance to use the shadow build logic of creator to get it to work?

I am not using the shadow build logic. I have setup the structure using the different variables of qmake as OBJECTS_DIR, MOC_DIR and others to separate code code, objects, libs and exes. Everything is stored where it is expected. However, the compilation is not always triggered.

[tobias.hunger]

That is correct. The dependency system in creator is rather limited and I think we should just remove it completely. There is just no way to extract all the necessary information from all the build systems we support (like: Is this a static or dynamic build).

This should work better when you put everything into one build system and let that sort out the dependencies.

[koahnig]

It is a static build of my application. Only Qt libs stay dynamic, but those are not changed anyway.

I thought the complexity of my projects is rather small. In my case it would be enough to include the lib as a dependency into the makefile of the application. But it looks like this seems to be simply missing.
That shocks me a bit.

[koahnig]

Thanks Tobias for your open words.

I have found a solution by adding PRE_TARGETDEPS to my project files. I thought that creator might do something similar. However, this might be a naive thinking when considering that creator would require a deep integration of qmake functionality then.

[tobias.hunger]

We want our users to be able to build their projects outside creator. Moving things like project dependency resolution into into Creator kind of ruins that.

We also want to support several build systems. Extracting all the details you need to do dependencies right from all of them is really hard.

Build systems already are really good at dependency handling... so we prefer to use those where possible.

[koahnig]

[quote author="Tobias Hunger" date="1355846235"]
Build systems already are really good at dependency handling... so we prefer to use those where possible.[/quote]
That is exactly the reason why I was wondering about the trouble I had.

It is certainly also clear that independent project handling cannot solve my problem.
Therefore, I agree that it would be better to remove the functionality from creator. At the moment it seem to deliver something which is actually impossible. It wastes a lot of time and it creates too much frustration.