How can I achieve that _without_ editing my own cmake file? What if a swap in a different library for my executable that is abi compatible but uses a different implemented to load images?
I'm not talking hypotheticals here: I literally have two versions of the library that use slightly different versions of libpng (one for desktop and one for android) and it's extremely inconvenient to be messing around with my cmake file every time I change my build target. Sure I can do a giant IF(TARGET MATCHES "Android") ... ENDIF, which I guess is what I will do for now, but it seems like a poor solution. Edit: woops; ment that to go to the list. ~ Doug. On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs <[email protected]>wrote: > Add the sub dependencies that library A has with target_link_libraries(): > > target_link_libraries(A png) > > -- > Glenn > > On 11 August 2011 10:02, Doug <[email protected]> wrote: > >> Hrm... this seems like something cmake should be able to do, but I don't >> know how to make it work. >> >> If I have library A, that depends on a library and an executable project >> that depends on library A, how can the executable project resolve the sub >> dependencies from A? >> >> Specifically libpng in my case: >> >> I have a library that depends on libpng. >> >> I run cmake to build the library no problem. >> >> Then I try to compile a program that depends on the library and get a heap >> of errors like: >> >> undefined reference to `png_set_read_fn' >> etc. etc. >> >> Presumably this is something about how I depend on the library? I'm using >> the LibFindMacros, so my cmake module looks like this for the library: >> >> include(LibFindMacros) >> >> find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS >> ${LIBNW_PKGCONF_INCLUDE_DIRS}) >> >> find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS}) >> >> set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR) >> set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES) >> >> libfind_process(LIBNW) >> >> I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but >> that isn't really appropriate in this case. >> >> ~ >> Doug. >> >> _______________________________________________ >> 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://www.cmake.org/mailman/listinfo/cmake >> > >
_______________________________________________ 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://www.cmake.org/mailman/listinfo/cmake
