[CMake] What's the best practice for a large project using multiple versions of package dependencies
David Cole
DLRdave at aol.com
Sun May 3 17:12:12 EDT 2015
The best practice is obviously not to have multiple version of the
same sub-project within your large project...
And if you really really have to, then ExternalProject is definitely
your friend, because you should completely and totally isolate the two
different versions of the sub-project, which would not even be close
to easy-to-do if you were incorporating sub-projects with
add_subdirectory.
I'll leave the rest to others on this mailing list to give advice,
because if I was involved in a project which even suggested multiple
versions of sub-projects simultaneously, I would run in the opposite
direction as fast as I could.
( ha ha :-) ... reminds me of my all-time favorite (and
most-down-voted ever) stackoverflow.com answer:
http://stackoverflow.com/questions/8153519/how-to-automatically-download-c-dependencies-in-a-cross-platform-way-cmake/8351140#8351140
)
D
On Sun, May 3, 2015 at 12:20 AM, Zhongle Wu <zhongle.wu at gmail.com> wrote:
> Dear CMakers:
>
> I'd like to have your advice for setting up CMakeLists files in a large
> project where I want a top level CMakeLists.txt manages the whole build
> hierarchical structure. Suppose I have some parallel sub-projects where one
> sub-project depends on VTK v5 and another sub-project depends on VTK v6, or
> different version of boost library, these sub-projects may also dependent on
> common sub-projects. I think it would be a common scenario in a large
> project that sub-projects or modules may dependent on different version of
> packages, and during the project lifetime, when a dependent package
> upgrades, not all of these sub projects have to upgrade the package version
> at the same time.
>
> I think that find_xxx commands are not very friendly into detect and use
> parallel versions of a package due to the global cache variables.
> FindQt.cmake seems support different version though.
>
> The ExternalProject_Add for super-build is very flexible. Although as it's
> name, it was designed initially for building external packages, it can be
> used to manage your own sub projects too. Using ExternalProject_Add for
> these sub-projects, I can specify different version of external packages.
> But I think it is not as elegant as add_subdirectory to manage the
> hierarchical structure in a single build.
>
> Instead of using the ExternalProject_Add, some people has successfully used
> python script to manage these build dependencies. But using external script
> language create other inconvenient issues such as the need of sharing some
> configuration variables between the external script and cmake.
>
> So what's the best practice in a build using multiple versions of packages
> under a top level CMakeLists, or simply just don't do that but splitting
> your sub-projects into multiple top level CMakeLists files?
>
> Thanks!
> Zhongle
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> 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
More information about the CMake
mailing list