Have I gone and confused everybody on this? :P --------- Robert Dailey
On Mon, Jan 23, 2012 at 6:01 PM, Robert Dailey <[email protected]> wrote: > As you know, in target_link_libraries(), you can specify "debug", > "optimized", or "general" to specify which configurations a library will be > applied to. > > I have developed a system to allow dependencies to recursively add their > own dependencies. Suppose we have 3 targets: > > A: > libx > liby > libz > > B: > foo > bar > A > > C: > A > B > > > Above, I list each target (A, B, C). The items under it are the targets it > depends on. So, target A depends on targets named libx, liby, and libz. > Similarly, target B depends on targets foo, bar, and A. > > When I flatten out all of the dependencies for target C, it looks like so: > > A > B > libx > liby > libz > foo > bar > > This is pretty simple, but each dependency listed can also have a "debug", > "release", or "general" next to it. So let's use the same example as last > time, but introduce some of these prefixes: > > A: > libx > liby > libz > > B: > foo > bar > A > > C: > debug B > > Above, since "B" is listed as "debug", library B and all of its > dependencies should only build in the debug configuration. So when we > flatten this out, you will see the following. Note that this flattened list > is what is sent to target_link_libraries() > > debug B > debug foo > debug bar > debug A > debug libx > debug liby > debug libz > > Now where this REALLY gets confusing, is when we have a mixture of > "conflicts", where the same target is specified as a dependency twice, but > with different configuration prefixes: > > > A: > libx > liby > libz > > B: > foo > bar > A > > C: > optimized A > debug B > > In this case, A's dependencies are specified as optimized, but B's are > specified as debug, but B also depends on A, so A's dependencies would be > debug as well. > > I need to implement a system that can handle such conflicts and resolve > them appropriately. For example, the way A's dependencies would be resolved > is by specifying them as "general" or no prefix at all, since the flattened > list includes them both in debug and optimized. So the final, flattened > list would look like: > > A > debug B > libx > liby > libz > debug foo > debug bar > > This is VERY complex and due to the way lists work and stuff, I can't > think of how to do this. Any tips? > > --------- > Robert Dailey >
-- 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
