[CMake] cyclic DLL dependencies

[Andy Lego]

Hello Michael,

You can also try co cleanup the API so you don't need the circular
dependency. This way you can still keep the library separate, but at
the same time reduce problems in the future.

Andy

On Thu, Mar 13, 2008 at 9:18 AM, Michael Wild <themiwi at gmail.com> wrote:
>
>  On 13Mar, 2008, at 15:56, David Cole wrote:
>
>  > The real solution is to make them into one library. If you can't
>  > have one without the other, then why bother having two? You have to
>  > have both by definition because of the two-way dependency. Why not
>  > consolidate them into one?
>  >
>  > Or... force them to be static libs (ADD_LIBRARY(... STATIC ...)) and
>  > link them both everywhere they need to be linked...
>
>
>  Thanks
>
>  But this is not possible. As I said, the smaller of the libraries must
>  be exchangeable. And multiple versions of a merged library is just a
>  no-go.
>
>  Michael
>
>
>
>  >
>  >
>  > HTH,
>  > David
>  >
>  >
>  >
>  > On 3/13/08, Michael Wild <themiwi at gmail.com> wrote: Hi all
>  >
>  >
>  > I'm converting a large code for *nix to cmake and in the process also
>  > would like to port it to Windows. Unfotunately, there are two two
>  > shared libraries with cyclic dependencies on each other. On *nix this
>  > is no problem, as it is legal that a shared library contains undefined
>  > symbols. Not so for DLLs.
>  >
>  > Under cygwin/MinGW I can tackle part of the problem with the .dll.a
>  > library which allows me to link a DLL which depends on the symbols in
>  > another DLL without explicitly linking against that second library,
>  > resulting in the behavior on POSIX systems where undefined symbols are
>  > resolved during loading.
>  >
>  > This, however does not work immediately in my case, as the
>  > dependencies are cyclic. So what I came up with, is first creating a
>  > fake library, which in addition to its normal source files contains
>  > the definitions for the code it depends on in the second library. From
>  > this I create the .dll.a file with the --out-impl option (as is
>  > default in win32 CMake), use that to link the second library and then
>  > I relink the first library, minus the additional definitions and plus
>  > the .dll.a from the second library.
>  >
>  > So far, so good. But how do I tell CMake? I first tried with a "fake"
>  > library target. This target has a distinct name, but the same
>  > OUTPUT_NAME as the "real" library. It is built from the files for the
>  > first library plus the ones it depends on from the second library.
>  > Then I have a target for the second library, depending on the "fake"
>  > library, which uses the .dll.a file produced.
>  > Lastly I have the "real" library target for the first library,
>  > depending on the second library and using its .dll.a.
>  >
>  >
>  > For me this worked so far. Only problem is, that one library is huge
>  > and the other very small, but it depends on large portions of the
>  > large one. So I could turn it as I would, I can't seem to avoid
>  > compiling large parts of the huge library twice!
>  >
>  > What would be ideal for me, is being able to "reuse" object files from
>  > one target in another target. However, I couldn't find anything on how
>  > to achieve this in the docs or using google.
>  >
>  > Does anyone of you have an idea how to solve the cyclic dependency
>  > problem in a more elegant way or how to "recycle" objects?
>  >
>  >
>  > Michael
>  >
>  > PS: Making the small library part of the large one is not an option,
>  > as the small one can be exchanged with other implementations before
>  > program start.
>  >
>  > _______________________________________________
>  > CMake mailing list
>  > CMake at cmake.org
>  > http://www.cmake.org/mailman/listinfo/cmake
>  >
>  >
>
>  _______________________________________________
>  CMake mailing list
>  CMake at cmake.org
>  http://www.cmake.org/mailman/listinfo/cmake
>



-- 
http://legoandy.com -o- http://capitalmtb.org

Support my 150 mile bike ride to fight MS:
http://bikecan.nationalmssociety.org/site/TR?px=3921627&pg=personal&fr_id=9066