Hum, I don't see what you mean. In the cmake spirit, my executable don't even know they will depend on lib4. exe1 just knows it depends on lib1. Then lib1 just knows it depends on lib3. Then, lib3 just knows it depends on lib4, i.e. lib4-A to build exe1-A and lib4-B to build exe1-B. (and in the real situation, there is not only one of these "dual" libraries, and the dependency chain is too complicated for us to keep maintaining it by hand).
Alexandre -----Message d'origine----- De : cmake-boun...@cmake.org De la part de Christopher Harvey Envoyé : jeudi 19 mars 2009 19:04 À : Alexandre Feblot Cc : cmake@cmake.org Objet : Re: [CMake] How to describe lib dependencies when a lib has different possible implementations? If you want to compile two execs, one for each static library you can use a two element list and go "for_each" over each library and create two execs. Otherwise you can just hardcode it into cmake. Alexandre Feblot wrote: > > Hi, > > in fact, in my current system, the implementation to use is pretty hardcoded > in each executable makefile, in the link line. There is no automatic lib > dependency management. > > > Alexandre > > -----Message d'origine----- > De : cmake-boun...@cmake.org De la part de Christopher Harvey > Envoyé : jeudi 19 mars 2009 17:58 > > Hi, > Interesting question. You said that > "only one of them has to be used in every executable, the implementation > to use is determined by the executable." > These are static libraries, so how can the exec pick one if it isn't > even built? (As opposed to loading one dynamically) > Basically I'm still wondering at what point you want the decision for > one of the two libraries to made and how you make that decision. > How exactly did you do it beforehand, without cmake? > CMake has IF statements, so I'm pretty sure it'll be no problem just > have no idea what you would put in those ifs. > > Chris. > > Alexandre Feblot wrote: > >> Hi, >> >> I'm facing an issue while trying to port my current build system to >> cmake and don't know is there is a way to solve it: >> >> In our project, we build a bunch of *static* libs (about 360) and >> several executables on them. >> >> * one library, in the middle of the lib dependency chain, has in fact >> 2 different implementations. That is to say, there are 2 different >> libs with the exact same interface, but they don't use the same >> back-end, have different source code, and don't have the same >> dependencies. >> * only one of them has to be used in every executable, >> the implementation to use is determined by the executable. >> >> Dependency graph example: "->" means "depends on" >> >> *exe1-A* -> lib1 -> lib3 -> *lib4-A* -> lib5 -> lib7 >> *exe1-B* -> lib1 -> lib3 -> *lib4-B* -> lib6 -> lib8 >> *exe2-A* -> lib2 -> lib3 -> *lib4-A* -> lib5 -> lib7 >> *exe2-B* -> lib2 -> lib3 -> *lib4-B* -> lib6 -> lib8 >> >> >> I'd like to keep using the standard cmake mechanism of dependency >> description in which every lib only defines on which other libs it >> depends, and let cmake compute the final link line. >> >> The question is: how can I express the dependencie of lib3 on >> lib4 whereas lib3 has only a single description, and we don't know >> when describing it, if we'll have to use lib4-A or lib4-B. (and >> anyway, depending on the executable, we'll have to use each of them). >> >> Is there any concept of "abstract" target (lib4 in my example) which >> could be "instanciated" in the executable description (as lib4-A or >> lib4-B in the example) >> >> >> Thanks, >> >> Alexandre >> >> >> This email was sent to you by Thomson Reuters, the global news and >> information company. >> Any views expressed in this message are those of the individual >> sender, except where the sender specifically states them to be the >> views of Thomson Reuters. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > > > This email was sent to you by Thomson Reuters, the global news and > information company. > Any views expressed in this message are those of the individual sender, > except where the sender specifically states them to be the views of Thomson > Reuters. > > > > _______________________________________________ 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 This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. _______________________________________________ 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
