On Sep 23, 2009, at 9:13 PM, ext Robert Caldecott wrote: > 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. :)
We are looking into "pimping" the pro file editor with actions that help you to do such things. Adding libs with the corresponding LIBS and PRE_TARGETDEPS in a cross platform way by just selecting the library file (and perhaps setting some options) would certainly be desirable :) ++ Eike > 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 -- Eike Ziller Software Engineer Nokia, Qt Development Frameworks Phone +49 (0)30 6392 3255 Fax +49 (0)30 6392 3256 E-mail [email protected] _______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
