[CMake] Complicated dependency handling between linux & windows

[Stefan Reuschl]

2013/6/10 Robert Dailey <rcdailey.lists at gmail.com>

> One thing I have setup on my CMake script framework on Windows is an
> alias system. During configure, I tell CMake where my package
> repository root is on a windows share. Inside of this repository,
> third party libraries are listed in a consistent structure. I have a
> manifest script where I list all of the supported libraries. Each one
> listed will be downloaded, extracted, and its include directories,
> library directories, and binary file locations are all stored and
> mapped to an alias. The manifest need not list every library in the
> repository. Only those we care about.
>

I'm using a similar system:
For each project (not only third party libraries) there's a configuration
file specifying the following:
- project type: either a binary package with prebuilt libs or source with
CMakeLists
- download location: like download step of ExternalProject
- dependencies: list of other projects
The CMake configure step starts with a list of main projects and
creates the dependency graph for the full workspace. All projects
are downloaded and source projects are configured/built/installed.
The dependencies between projects are resolved using find_package:
Binary packages contain a simple hand-written ProjectConfig.cmake file
to set include directories and library locations. For source projects the
ProjectConfig.cmake file is created by cmake.

Compared to your described approach, the usage of ProjectConfig.cmake
seems to allow moving most of the framework code out of the actual projects,
which just require CMAKE_MODULE_PATH to be set to the download/install dirs
of the dependent projects and find_package can be used no matter how the
dependent projects have been built.

I totally agree that frameworks like these are difficult to maintain and a
more
general solution integrated into CMake would be very nice...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130612/a6c2c9d5/attachment.htm>