[CMake] Complex problem : recursive dependency configurations

[Robert Dailey]

Have I gone and confused everybody on this? :P

---------
Robert Dailey


On Mon, Jan 23, 2012 at 6:01 PM, Robert Dailey <rcdailey at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120124/eca9e111/attachment-0001.htm>