<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/6/10 Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":100" style="overflow:hidden">One thing I have setup on my CMake script framework on Windows is an<br>
alias system. During configure, I tell CMake where my package<br>
repository root is on a windows share. Inside of this repository,<br>
third party libraries are listed in a consistent structure. I have a<br>
manifest script where I list all of the supported libraries. Each one<br>
listed will be downloaded, extracted, and its include directories,<br>
library directories, and binary file locations are all stored and<br>
mapped to an alias. The manifest need not list every library in the<br>
repository. Only those we care about.<br></div></blockquote></div><br>I'm using a similar system:</div><div class="gmail_extra" style>For each project (not only third party libraries) there's a configuration</div>
<div class="gmail_extra" style>file specifying the following:</div><div class="gmail_extra" style>- project type: either a binary package with prebuilt libs or source with CMakeLists</div><div class="gmail_extra" style>- download location: like download step of ExternalProject</div>
<div class="gmail_extra" style>- dependencies: list of other projects</div><div class="gmail_extra" style>The CMake configure step starts with a list of main projects and</div><div class="gmail_extra" style>creates the dependency graph for the full workspace. All projects</div>
<div class="gmail_extra" style>are downloaded and source projects are configured/built/installed.</div><div class="gmail_extra" style>The dependencies between projects are resolved using find_package:</div><div class="gmail_extra" style>
Binary packages contain a simple hand-written ProjectConfig.cmake file</div><div class="gmail_extra" style>to set include directories and library locations. For source projects the</div><div class="gmail_extra" style>ProjectConfig.cmake file is created by cmake.<br>
</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>Compared to your described approach, the usage of ProjectConfig.cmake</div><div class="gmail_extra" style>seems to allow moving most of the framework code out of the actual projects,</div>
<div class="gmail_extra" style>which just require CMAKE_MODULE_PATH to be set to the download/install dirs</div><div class="gmail_extra" style>of the dependent projects and find_package can be used no matter how the</div>
<div class="gmail_extra" style>dependent projects have been built.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>I totally agree that <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">frameworks</span> like these are difficult to maintain and a more</div>
<div class="gmail_extra" style>general solution integrated into CMake would be very nice...</div></div>