On Wed, 2009-12-23 at 14:12 +0100, Michael Wild wrote: > On 23. Dec, 2009, at 13:28 , Marcel Loose wrote: > > > On Wed, 2009-12-23 at 13:09 +0100, Michael Wild wrote: > >> On 23. Dec, 2009, at 12:08 , Marcel Loose wrote: > >> > >>> Hi all, > >>> > >>> I suggested this in the quite long thread "third party library > >>> dependencies", but it may have been overlooked. Hence, I started a new > >>> thread. > >>> > >>> Upon (re)reading the Mandriva page > >>> http://wiki.mandriva.com/en/Overlinking, I was thinking: maybe the issue > >>> of overlinking can be solved more or less the same way as pkg-config > >>> does: i.e. by defining private dependencies. This could be an extra > >>> option to target_link_libraries. > >>> Something like: > >>> > >>> target_link_libraries(mylib public1 public2 PRIVATE private1 private2) > >>> > >>> This would tell CMake that mylib directly depends on public1 and public2 > >>> and should only link in these two libraries when these are shared > >>> object libraries; otherwise private1 and private2 would also need to be > >>> added on the link line. > >>> > >>> The big hurdle to take, of course, is to detect in a > >>> platform-independent way whether the given library is shared or static. > >>> However, a lot of this knowledge is already available in the diverse > >>> Modules/Platform macros, so my feeling is that this should be feasible. > >>> > >>> Best regards, > >>> Marcel Loose. > >>> > >> > >> You would also need a PUBLIC keyword, and then require that all > >> FindXXX.cmake modules prefix their libraries with PUBLIC and PRIVATE. If > >> only the PRIVATE libraries where prefixed, the following would not work if > >> A_LIBRARIES contains PRIVATE: > >> > >> find_package(A) > >> find_package(B) > >> add_library(C source.c) > >> target_link_libraries(C ${A_LIBRARIES} ${B_LIBRARIES}) > >> > >> Because then all the B_LIBRARIES would be considered to be private > >> "details" of the public A_LIBRARIES... Also, there's no way to tell CMake > >> which of the private libraries belongs to which of the public libraries. > >> > >> I think it would be better if a FindXXX.cmake module marked the private > >> libraries as a property of the public libraries and then let CMake take it > >> from there (although as of now I wouldn't know on what to set the > >> property, except if the module created an IMPORTED target for each of the > >> public libraries, but that bears the possibility of target name collisions > >> with the importing project). > >> > >> Michael > > > > Hi Michael, > > > > I don't think you'll need to prefix the library names with either > > PRIVATE_ or PUBLIC_. CMake could figure out whether "public1" and > > "public2" are shared or static libraries. If they are shared libraries, > > then the libraries marked as private ("private1" and "private2") do not > > have to be linked in as well. Otherwise they must also be linked in. I > > assume that CMake keeps a list internally, of all dependent targets; the > > private libs should only be added to that internal list if the public > > libs are static libs. > > > > I don't completely understand your example. Are you suggesting that > > you'll run into trouble if you have a library named "PRIVATE"? I think > > name clashes will currently occur as well if I name my library "debug", > > "optimized", or "general". > > > > Maybe, it would be better if the FindXXX modules would handle this. On > > the other hand, you then depend on third parties to properly update > > their FindXXX modules, or have to rewrite them yourselves :-( > > > > Best regards, > > Marcel Loose. > > > > > No, it won't work. For example, if FindA.cmake does > > set(A_LIBRARIES /some/path/libA.so > PRIVATE /some/other/path/libX.a /some/other/path/libY.a) > > and FindB.cmake contains > > # notice that this is a static library! > set(B_LIBRARIES /some/path/libB.a) > > > then the call > > target_link_libraries(C ${A_LIBRARIES} ${B_LIBRARIES}) > > expands to (wrapped for legibility > > target_link_libraries(C > /some/path/libA.so > PRIVATE /some/other/path/libX.a > /some/other/path/libY.a > /some/path/libB.a) > > which is different in meaning from > > target_link_libraries(C ${B_LIBRARIES} ${A_LIBRARIES}) > > which becomes > > target_link_libraries(C > /some/path/libB.a > /some/path/libA.so > PRIVATE > /some/other/path/libX.a > /some/other/path/libY.a) > > In the first case libB.a becomes marked as PRIVATE of libA.so! Not very nice > if you ask me ;-) > > Michael
Hi Michael, I never suggested that A_LIBRARIES should be set to contain "PRIVATE". I suggested to add a keyword "PRIVATE" to the target_link_libraries command. Of course, if you want to abuse CMake, it's always possible. For example, the following CMakeLists.txt file will not be processed by CMake, because I decided in my eternal wisdom (sic) to name one of my libraries "optimized". My OS doesn't bother that I use that names; it's just a "limitation" of CMake. cmake_minimum_required(VERSION 2.6) project(Dummy) add_library(debug debug.cc) add_library(optimized optimized.cc) target_link_libraries(debug optimized) CMake Error at CMakeLists.txt:5 (target_link_libraries): The "optimized" argument must be followed by a library. Argument? "optimized" is the name of my library! Best regards, Marcel Loose. _______________________________________________ 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
