The last time I tried PRE_TARGETDEPS I couldn't get it to work, but I have had more success today, but it's painful to get this working for all O/S types.
I agree with your rant and FWIW I think QtCreator should take care of this level of detail and add full support for creating projects of this type (SUBDIRS, with dependent static libs, multiple EXEs, etc.) without the need for us to go anywhere near a .pro file - it could sort out all the O/S idiosyncrasies with LIBS/PRE_TARGETDEPS for you. Man, that would be so sweet. I would never ask for another feature again. They are so close... sessions don't do it for me you see, SUBDIRS are a much better idea IMHO. We can only hope. :) 2009/9/23 KC Jones <[email protected]>: > 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 > > _______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
