Edit Question - KnowledgeHub

Title Body

I've got a CMake project that includes and links against two libraries, say A and B (actually it's more than two and one of them is boost stuff, but that doesn't really matter here). Both are located via FindSomething.cmake scripts that (correctly) populate the standard CMake variables such that include directories are added via INCLUDE_DIRECTORIES(${A_INCLUDE_DIRS}) INCLUDE_DIRECTORIES(${B_INCLUDE_DIRS}) and linking is later done via TARGET_LINK_LIBRARIES(mytarget ${A_LIBRARIES} ${B_LIBRARIES}) Now, the problem is that both libraries can either reside in a user based location or in the system directories (I'm on linux by the way, CMake 2.8.2) - or in both. Let's say A is only in $HOME/usr/include and $HOME/usr/lib while B (boost in my case) resides in both the system paths ( /usr/include and /usr/lib ) AND in the user based paths - in different versions. The find scripts can be made to find either the system or the user-based library B , this works. The trouble starts when I want to link against B from the system paths. ${B_INCLUDE_DIRS} and ${B_LIBRARIES} correctly point to the system-wide locations of the headers and libraries. But there is still ${A_INCLUDE_DIRS} that points to a non-system include directory and ultimately also the headers for library B are taken from this location, while the linking for B uses the version from the system paths (via ${B_LIBRARIES} ) which leads to conflicts, i.e. linking errors. Changing the order of the INCLUDE_DIRECTORIES statements does not seem to change anything. I checked the origin of the symbols that cause the linking errors via nm --line-numbers on the object files. What can I do? Is there

Tags (comma-separated) Cancel