So, before I run around with my hair on fire, let me say thanks for pointing me in the general direction of PRE_TARGETDEPS. That appears to be the missing ingredient. I haven't worked it into my project successfully yet, but I was able to take your minimal sample and play with it to gain some understanding. I put the foo and bar libs in separate directories, encountered my initial problem with a build error like:
make[1]: *** No rule to make target `libbar.a', needed by `main.app/Contents/MacOS/main'. Stop. and fixed it by adding more relative path brittleness to the PRE_TARGETDEPS decl. Thanks. I mean it. BUT W.T.F.???!!!##### For the love of ganja, when would I possible not want to relink when a dependent static lib changes? Just f'ng relink the beast. Don't make me tell you to do so. Educate me about why PRE_TARGETDEPS is a good and useful thing. What possible use case is there for this? When would a computer not to a better job of figuring out when the link should be executed? Good old 'make' has many painfully glaring flaws -- but making me manually declare build dependencies in duplicate is not one of them. And in a platform dependent way no less. And in a way that makes me declare the specific relative paths of my project. Is it not enough that I've had to declare my libs and the paths where they are found? I think it is. So my current project has something like 15 static libraries linked in. More are planned. The structure changes frequently. A few are system libs. I suppose I won't declare them in PRE_TARGETDEPS since I really, really don't want to add extra brittleness to my build scripts by declaring particular OS paths. But now I have to take my LIBS decl and manually translate that into a PRE_TARGETDEPS??? And remember to change this whenever libraries are added or removed? Really? Wow. Again, thanks for your help. Sorry for the outburst. But my head exploded and I felt the need to share with the group.... Sorry if any stray bits of grey matter splattered on your keyboard... On Tue, Sep 22, 2009 at 2:17 PM, Andre Poenitz < [email protected]> wrote: > On Tue, Sep 22, 2009 at 11:27:03AM -0700, KC Jones wrote: > > The discussion of separate include and src directories raises a few > > questions: > > > > First: > > Has the issue of building hierarchical projects using SUBDIRS been > solved? > > Specifically the issue where changes to sources of a static library do > not > > trigger a relink of the dependent application. I missed a few threads > about > > SUBDIRS support, so sorry if this has been discussed. I might be willing > to > > upgrade to a HEAD version if this problem has been addressed. Having to > > remember to touch some source in the main app project is a major pain... > > Can you please post a (really minimal) project that exposes the problem? > I have a hard time reproducing your troubles. I.e. given > > -- foo.cpp -- > int foo() { return 42; } > > -- foo.pro -- > TEMPLATE = lib > CONFIG += staticlib > SOURCES += foo.cpp > > -- bar.cpp -- > int foo(); > int bar() { return foo() + 1; } > > -- bar.pro -- > TEMPLATE = lib > CONFIG += staticlib > SOURCES += bar.cpp > > -- main.cpp -- > int bar(); > int main() { return bar(); } > > -- main.pro -- > SOURCES += main.cpp > PRE_TARGETDEPS = libfoo.a libbar.a > LIBS += -L$$PWD -lbar -lfoo > > -- all.pro -- > TEMPLATE = subdirs > SUBDIRS = foo.pro bar.pro main.pro > CONFIG += ordered > > running > > qmake -r && make > > followed by > > touch foo.cpp && make > > rebuilds libfoo.a and main. > > > Second, not really a Creator question, but it impacts my use of Creator > > significantly: > > Is there some trick to using LUPDATE on projects or subprojects where the > > sources are not in the same directory as the .PRO/.PRI files? So far I > have > > not been able to make it work. I have a .PRO with something like: > > > > HEADERS += include/XXX/Version.h \ > > src/XXXApplication.h \ > > src/foobar.h > > SOURCES += src/XXXApplication.cpp \ > > src/foobar.cpp > > > > And LUPDATE fails on this completely. > > Again, please make this a minimal, reproducible example. > > > Third, onto the wishing: > > Is there any thought to integrating Qt translation tools into Creator? > > There is such thought, but as the gain would be minimal and there are > more pressing needs all over the place it ranks pretty low. > > This might change, of course, if someone would come up with a > ready-to-integrate implementation ;-) > > Andre' > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.trolltech.com/mailman/listinfo/qt-creator >
_______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
