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.hanw...@kitware.com> wrote: > On Sat, Mar 17, 2012 at 5:03 PM, Bill Lorensen <bill.loren...@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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
