Quantcast

Cross project include/link pathing?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cross project include/link pathing?

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cross project include/link pathing?

Andreas Naumann
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
Loading...