[CMake] Avoiding error when using add_subdirectory twice on same path (CMake 2.6.4)

[David Cole]

What is your CMake code for this "diamond dependency" case?

Is there a separate directory for each of the libs involved?

Whichever CMakeLists file glues them all together should be able to
add_subdirectory just once on each of them.... Why do you need two
add_subdirectory calls for commonLib?


On Tue, Jun 16, 2009 at 6:23 PM, Tyler Roscoe <tyler at cryptio.net> wrote:

> On Tue, Jun 16, 2009 at 06:04:17PM -0400, Bill Hoffman wrote:
> > This was never expected to work, and CMake creates "bad" makefiles in
> > versions of CMake prior to this.   Basically, CMake was over-writing the
> > makefiles as many times as the directory was there.  This causes very
> > odd things to happen, and there were many reports of CMake is broken
> > because of this.   It caused incorrect percent done reporting and
> > sometimes failed to build some targets altogether.   If it was working
> > for you, you were getting lucky (or unlucky...).
>
> It does work well for us with CMake 2.6.2. I have never seen a progress
> report > 100% or any other problems that I would attribute to this.
>
> If you can only add a particular source subdirectory once, how do you
> handle a "diamond dependency":
>
>
>   myApp
>  /    \
>  /      \
> lib1   lib2
>  \      /
>  \    /
>  commonLib
>
> lib1 and lib2 both need commonLib, so they both do
> add_subdirectory(commonLib). I suppose you could rely on myApp to
> perform the add_subdirectory(), but what if I want to build just lib1 or
> just lib2 and not build myApp?
>
> tyler
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090616/aa717d74/attachment.htm>