Dependency managment

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

Dependency managment

Ciccio Pasticcio
Hi all,
we are trying to re-design the build system of an existing complex project using cmake.
We have a source tree such this (it is only an example to help explaining the problem)

.
└── libs
    ├── CMakeLists.txt  
    ├── libA
    │   ├── CMakeLists.txt
    │   ├── include
    │   │   └── libA.h
    │   └── source
    │       └── libA.cpp
    └── libB
        ├── CMakeLists.txt
        ├── include
        │   └── libB.h
        └── source
            └── libB.cpp

The tree contains libraries and executables and many of them have some dependencies to be
satisfied. We wrote a CMakeLists.txt file on top of the hyerarchy which repetitively uses the
add_directory directive to build every project under it. This solution seems to work well
until a project needs another one to be built; in other words, we did not find out how to deal
with dependencies. Looking at the tree above, we can compile libA but we cannot compile libB without
installing libA because the latter needs it. What's the right and easy way to make a target globally
available or at least available for projects on the same level?

Thanks,
Gabriele

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Dependency managment

Attila Krasznahorkay
Hi Gabriele,

What do you mean exactly by "we can compile libA but we cannot compile libB without installing libA because the latter needs it"? o.O Are you trying to find libA in libs/libB/CMakeLists.txt with find_package(...)?

"Normal" targets (libraries and executables) should be globally visible after you defined them. This is the default behaviour of CMake. So if you define libA correctly, you would just need to link libB against it (using target_link_libraries(...)) for the whole thing to work correctly. (libB waiting for libA to finish, and then using its headers and linking against its library file.)

There are literally countless number of examples out there in the wild for doing this. Here is one example for instance:

https://gitlab.com/atomki-nuclear-phys/cda

That project also very generously uses add_subdirectory(...). And targets in the subdirectories depend on each other in not completely trivial ways. (Mind you, as long as you set everything up correctly, it doesn't even matter in which order you include the subdirectories. It's fine to first include one that depends on a library whose definition is only included later on.)

Cheers,
             Attila

> On 12 Dec 2018, at 14:01, Ciccio Pasticcio <[hidden email]> wrote:
>
> Hi all,
> we are trying to re-design the build system of an existing complex project using cmake.
> We have a source tree such this (it is only an example to help explaining the problem)
>
> .
> └── libs
>     ├── CMakeLists.txt  
>     ├── libA
>     │   ├── CMakeLists.txt
>     │   ├── include
>     │   │   └── libA.h
>     │   └── source
>     │       └── libA.cpp
>     └── libB
>         ├── CMakeLists.txt
>         ├── include
>         │   └── libB.h
>         └── source
>             └── libB.cpp
>
> The tree contains libraries and executables and many of them have some dependencies to be
> satisfied. We wrote a CMakeLists.txt file on top of the hyerarchy which repetitively uses the
> add_directory directive to build every project under it. This solution seems to work well
> until a project needs another one to be built; in other words, we did not find out how to deal
> with dependencies. Looking at the tree above, we can compile libA but we cannot compile libB without
> installing libA because the latter needs it. What's the right and easy way to make a target globally
> available or at least available for projects on the same level?
>
> Thanks,
> Gabriele
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

--

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:
https://cmake.org/mailman/listinfo/cmake