Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
0.2
-
None
-
Fully updated Mac OS 10.7, Xcode 4.5, clang 4.1.
-
1d067c0957c56b5926931132cf43853e57a7361e
Description
I've attached a small project/product heirarchy. The "master" project is in b/c.qbp, and it depends on the dynamic library a, which is described in b/a.qbs and whose sources are found in a/.
As can be seen, both b/c/c.cpp and a/a.cpp include a/a.hpp. However, when I touch (or change more deeply) a/a.hpp, neither of those two cpp files get rebuilt! /Something/ gets propagated though, since both the library and the executable get /relinked/ … but the object files do not get rebuilt so this is a bit moot!
Humber:qbsTest williamg$ cd b/ Humber:b williamg$ ~/Projects/Tools/qbs-bm/bin/qbs clean Found project file /Users/williamg/Projects/qbsTest/b/c.qbp Humber:b williamg$ ~/Projects/Tools/qbs-bm/bin/qbs Found project file /Users/williamg/Projects/qbsTest/b/c.qbp loading project took: 27 ms build graph took: 7 ms for qt-macports-debug: - [hpp, dynamiclibrary] a as qt-macports-debug - [hpp, application] c as qt-macports-debug compiling a.cpp compiling c.cpp linking liba.dylib linking c Build done. Humber:b williamg$ touch ../a/a.hpp Humber:b williamg$ ~/Projects/Tools/qbs-bm/bin/qbs Found project file /Users/williamg/Projects/qbsTest/b/c.qbp for qt-macports-debug: - [hpp, dynamiclibrary] a as qt-macports-debug - [hpp, application] c as qt-macports-debug linking liba.dylib linking c Build done.
What's going on here? It's trivial to see these dependencies:
Humber:b williamg$ clang -I.. -c -MD ../a/a.cpp Humber:b williamg$ cat a.d a.o: ../a/a.cpp ../a/a.hpp Humber:b williamg$ clang -I.. -c -MD c/c.cpp Humber:b williamg$ cat c.d c.o: c/c.cpp ../a/a.hpp
… so how is QBS failing to detect them? I notice that QBS does not use the *.d dependency files which the compiler will generate for you for free when building an object … which does ring alarm bells for me! But that discussion is better had in a mailing list than in this specific bug!