Dear Chris,
your description looks like the perfect example for ExternalProject_add.
Than, every library would be a project. Inside each library, it looks
for its dependency using find_package(<libraryProjectName>) and exports
the dependency chain.
Your CMakeLists.txt of the application than has two possibilities:
a) simply assume, that the library is installed in a (known)
location -> use find_package as described above and proceed as is.
b) build the library as an external project. In this case, your
application has to be an external project with dependency to the
external project of the library.
Hope that helps you and describes at least the idea,
Andreas
Am 09.02.2017 um 22:26 schrieb Chris Johnson:
We've been using CMake for a couple of years for C++ application
building. We effectively set up our CMake project structure once, and
mostly only change it to add new source files, etc.
Currently, all C++ source is checked out of our SVN repository into one
large tree. This tree actually contains multiple applications. Many,
but not all, depend on libraries which are also in this same source tree
checkout. Executables are statically linked to the libraries.
Our source tree has grown to the point where this arrangement really
does not make sense, and is quite far from best practices. We want to
move to a more project-oriented structure, where there will be multiple
projects, but where the libraries are still shared.
How do I go about this?
In particular, how do I structure each project to find the common,
shared (but statically linked) libraries? I would assume that each
library itself or the collection of libraries would be a project, with a
top-level CMakeLists.txt file.
Note that each project could be installed in its own unique location in
its deployed VM or container, so placing the libraries into, say,
hard-coded /usr/local/lib is not a feasible solution for us.
Pictorially (use fixed width font for best results):
=====================================================
Current single source tree layout
---------------------------------
.
|-- CMakeLists.txt
|-- application_1/
| `-- CMakeLists.txt
|-- application_2/
| |-- CMakeLists.txt
| |-- util_1/
| | `-- CMakeLists.txt
| |-- util_2/
| | `-- CMakeLists.txt
| `-- util_3/
| `-- CMakeLists.txt
`-- lib/
|-- CMakeLists.txt
|-- lib_1/
| `-- CMakeLists.txt
`-- lib_2/
`-- CMakeLists.txt
Desired project-oriented layout
-------------------------------
[Application 1 Project]
.
`-- CMakeLists.txt
[Application 2 Project]
.
|-- CMakeLists.txt
|-- util_1/
| `-- CMakeLists.txt
|-- util_2/
| `-- CMakeLists.txt
`-- util_3/
`-- CMakeLists.txt
[Libraries Project]
.
|-- CMakeLists.txt
|-- lib_1/
| `-- CMakeLists.txt
`-- lib_2/
`-- CMakeLists.txt
Presently, all of the applications know where to find the library header
files, because they are all in the same tree. When we run "cmake ." at
the root of the source checkout, CMake knows where everything is, and
correctly provides the include paths to C++ compiler.
Similarly, at link time, CMake has automatically determined where the
compiled static libraries are, and our CMakeLists.txt files only need
mention them by name. CMake has been brilliant at making this kind of
stuff simple.
But how do I make CMake generate the correct include and link paths when
"cmake ." is run on some individual project's source code, when those
paths will be outside the current tree, i.e. elsewhere?
..chris
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
