clin...@elemtech.com wrote: > I'm already aware of the distinction.
Great. That wasn't clear from your email talking about all dependencies of QtDeclarative instead of just the public ones. > Granted, UseQt4.cmake doesn't know > if imported targets are being used or not, and probably cannot be reduced > to the public dependencies. Yes, I think the 'module dependencies' from the point of view of cmake determining that the library exists and has been found on the system is different to the 'public link dependencies'. > But, aren't you still missing the private dependencies so that the > -rpath-link flag (for Linux/GNU) can be added to specify the location of > the private dependencies? That is not in the intended scope of my change. My change is about the public link dependencies. If you know how to specify the private dependencies correctly, we can have that patch depend on my patch. I'm focussing on the public link dependencies. > Maybe we can always use imported targets in FindQt4.cmake, then end up > with one place to specify public & private dependencies. The IMPORTED targets are available in UseQt4.cmake. The public dependencies (and private dependencies, if you populate them there in some way) can be read from the IMPORTED targets in UseQt4.cmake. That's also out of the scope of my patch though. I'm trying to get a patch that is self-contained and useful in. I'm not trying to fix all possible issues with FindQt4 at once. There are more other and useful things to do, but this is the largest issue and the one with the biggest gain. Do you think my patch is not self-contained and useful enough as it is to go in? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers