[CMake] Incorporating third party libraries

[Daniel Dekkers]

On Oct 4, 2011, at 4:24 PM, Clifford Yapp wrote:

> On Tue, Oct 4, 2011 at 7:20 AM, Daniel Dekkers <d.dekkers at cthrough.nl> wrote:
> Hi,
> 
> Would really appreciate your advice on this.
> 
> We are planning to use and maybe distribute a library (let's call it OurLib) that depends on third-party libraries, namely Boost, Glut, OpenGL, FreeType, Bullet, PNG, ...
> 
> You could take a look at what BRL-CAD does for this situation:
> 
> http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk  (look for adding the src/other subdirectory in CMakeLists.txt)
> http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/
> 
> macros used are defined in:
> 
> http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/misc/CMake/

Ok, thanks, will take a look.

> From a high level, our approach is to try to detect suitable installations of libraries on the system.  If we find them, use them.  If not, build our local copy. 

Ok. 
For me, in a perfect world, I would like to be able to do this for a top level CMakeLists.txt...

project(all)
add_subdirectory(lib0)
add_subdirectory(lib1)
...
add_subdirectory(app0)
add_subdirectory(app1)

... if I want to see and manipulate the sources of these libraries.
And if i don't, just use the binaries...

project(all)
find_package(lib0 ...)
find_package(lib1 ...)
...
add_directory(app0)
add_directory(app1)

And be "free" in that. So i could also do a local build of an individual library and just link directly to that binary.

> Currently our approach requires that each third-party library also have a functional CMake build,

Yes. Most libraries we use have that, or are at least getting there. We've "investigated" somewhere around 8-10 libraries as of now. I get the impression that library developers are willing to provide a CMake build, probably because it helps them too, internally. But often the find_package(), is lacking. The library developers don't feel responsible for the find[Package].cmake script, they don't see it anyway because (of course) they are mostly looking at the source code of their own library. So,... Kitware, or someone else will write it instead, but only as a reaction to the latest version of the library, which might have changed in the meantime (which is the case with Bullet at this moment, for instance). So some libraries (like OpenSceneGraph) just provide their own long list of find[Package].cmake scripts, and redirect with set(CMAKE_MODULE_PATH ...) which (i think) is a pity, because everybody wants these scripts, shipped with the official CMake distribution. But I realize that this is a lot of work, because you have to communicate with all the individual library developers.

> but in principle you could try adding support for other systems with ExternalProject_Add as well.  We found it simpler to just write CMake logic where needed, since in theory we need all of our third-party deps to build in every situation

Yes

> BRL-CAD itself needs to build in - rather than worry about whether the third-party library has enough build systems defined to cover all those cases (and figuring out how to trigger which one when) it proved simpler to write the CMake logic for the library.  Eventually, we'd like to have upstream adopt the CMake logic and we could just use their source archives unaltered, but we're a ways away from that and some projects are pretty heavily invested in Autotools.

Ok

> Cheers,
> CY

Thanks,
Daniel Dekkers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111004/8886998c/attachment.html>