[CMake] ExternalProject_Add examples

Bill Lorensen bill.lorensen at gmail.com
Sat Mar 17 17:51:13 EDT 2012


I agree, most all super builds are tricky. Is it practical to collect
examples are are they so Project specific they won't be useful. For
example, the Slicer4 external;s have a bunch of Slicer-specific stuff
in them.

However, it is still frustrating to star a superbuild from scratch.
Maybe we can collect a skeleton for each external package.

Bill

On Sat, Mar 17, 2012 at 2:11 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Sat, Mar 17, 2012 at 5:03 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Folks,
>>
>> I've recently created a number of super builds using CMake's External
>> Project mechanism. Each external project requires some sort of
>> download, configuration, build and possibly install. The CMake defines
>> needed to correctly access the results of the external project vary
>> significantly. The trickiest part is find the proper download,
>> configuration and CMake defines.
>>
>> For example, for the Point Cloud Library (http://pointclouds.org/) I
>> created these external projects:
>> VTK - git, cmake, make; VTK_DIR
>> FLANN - zip, cmake, make install; FLANN_LIBRARY, FLANN_INCUDE_DIR
>> Eigen - .tar.bz2,; EIGEN_INCLUDE_DIR
>> Qhull - git, cmake, make;QHULL_LIBRARY,QHULL_INCLUDE_DIR
>> Boost - .tar.gz, bootstrap.sh, b2; BOOST_ROOT
>> GTest - .zip, cmake, make; GTEST_ROOT,GTEST_INCLUDE_DIR
>>
>> Slicer4 has many more.
>>
>> Should we start collecting sample ExternalProject_Add files for
>> external projects?
>
> We have talked about doing this too (I have Eigen, Boost, GTest and
> others for example). The standard CMake based projects hardly seem
> worth it, but it depends on what you want to do with them I suppose.
> For the work we are doing in chemistry we have been working on an
> experimental superbuild that uses a common prefix in the build tree to
> install to, and then all we need pass in is CMAKE_PREFIX_PATH - this
> can make the logic significantly easier for dependent CMake projects
> as it will always search within the prefix first.
>
> The Qt external project was pretty tricky too, and we are using that
> in several places along with smaller libraries like libxml2.
>
> Marcus



-- 
Unpaid intern in BillsBasement at noware dot com


More information about the CMake mailing list