[CMake] linking hared libraries

[Chuck Atkins]

>
> On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth
> <gurenchan at gmail.com> wrote:
> > Also you said the PROJECT() should only be defined once, but shouldn't
> each
> > cmakelists.txt contain a project() or else cmake complains at me.
>
>
> According to the last paragraph of:
>
> https://cmake.org/cmake/help/v3.0/command/project.html
>
> you only need a PROJECT () in the top-level CMakeLists.txt...
>

While this is true, you only need it called once at the top level, there
are use cases where you see multiple calls to project() in aa given tree.
Usually this is in the case of adding independent third party libraries.
For example, imagine a source tree like:

/CMakeLists.txt
/src/CMakeLists.txt
/src/file1.cxx
/src/file2.cxx
/thirdparty/CMakeLists.txt
/thirdparty/libfoo/CMakeLists.txt
/thirdparty/libfoo/foo.h
/thirdparty/libfoo/foo.cxx
/thirdparty/libbar/CMakeLists.txt
/thirdparty/libbar/bar.h
/thirdparty/libbar/bar.cxx

Here, you may have project() called in /CMakeLists.txt,
/thirdparty/libfoo/CMakeLists.txt, and /thirdparty/libbar/CMakeLists.txt.
This would mean that libfoo and libbar are are independent projects that
can be built on their own, outside of the top level project.  This is
generally discouraged nowadays and is replaced by using ExternalProject but
prior to that module it was a common way to create a "superbuild" of many
CMake-based dependencies.  You still see it's use in many projects that
have been around a long time, i.e. VTK, ITK, etc.  It's even how CMake
itself manages building it's own version of it's dependencies (liblzma,
libcurl, libarchive, etc.).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151020/8a4e9f28/attachment.html>