On Tue, Jun 4, 2013 at 3:38 PM, Brad King <[email protected]> wrote: > On 06/03/2013 03:38 PM, Nicolas Tessore wrote: >> As far as I can see, there is just one possible issue with this. >> Say there is "libfoo.a" in two locations, ie. "/usr/lib" and >> "/usr/local/lib". If "/usr/lib" comes first in LIBRARY_SEARCH_PATHS, >> it is impossible to link to "/usr/local/lib/libfoo.a". > > A more common case like this is when a project uses two library > targets with the OUTPUT_NAME target property to produce a shared > and static library in the same directory with the same name e.g. > libfoo.a and libfoo.dylib. Then -lfoo will not know which one > to get, but a full path specifies the right one exactly.
The old problem that Xcode will force the dylib version on you. I've seen people work around this by adding a "Copy Files" build phase before compiling which gathers all external libs into the build product directory. That way, you'll end up with exactly the right files in the place where the linker looks first. It would be necessary to exclude intra-project and cross-project libraries from this though. > So we have a trade-off between correct one-time builds versus > correct cross-project rebuild dependencies. Getting rid of the post-build step would be nice for intra-project dependencies as well. N. -- 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
