Hi Alan, You could look at: https://github.com/davidsansome/python-cmake-buildsystem
More particularly this commit: - Export targets from both the installed and build tree [1] - Add generation of <PROJECT_NAME>Config.cmake [2] [1] https://github.com/davidsansome/python-cmake-buildsystem/commit/73134d77881ae6648a8f98daaf8630130b7f54ea [2] https://github.com/davidsansome/python-cmake-buildsystem/commit/3f504d8be5b41086f615494517ddd2cf66f4d365 This was based on the explanation of Alexander Neundorf. See http://www.cmake.org/pipermail/cmake/2013-February/053689.html We should really update the following tutorial: http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file Remark about the "export(PACKAGE ...)" statement: Based on my experience, it turns out that exporting the build tree in the system package registry is a bad idea when building the same package multiple time as it is done on a dashboard client or a developer workstation trying out multiple configurations. Indeed, when "find_package" is used in "CONFIG" (or "NO_MODULE") mode, by default CMake will search into the CMAKE_SYSTEM_PACKAGE_REGISTRY and will resolve to an already generated build tree instead of the one passed using <PROJECT_NAME>_DIR. Hth Jc On Thu, Mar 28, 2013 at 1:17 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>wrote: > On 2013-03-28 12:25-0400 David Cole wrote: > > CMake needs no new Find modules. >> >> All projects should provide a "project config file .cmake script" >> readable by CMake's find_package, and installed in a location where CMake >> can find it, so that a CMake find module is completely unnecessary. >> > > Hi David: > > Your idea sounds like a good one, but can you recommend an easily > understood > project that follows this approach that would serve as a good template > for build-system developers to use when implementing this approach for > their own projects? > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/** > opensource/opensource.html<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<http://www.cmake.org/Wiki/CMake_FAQ> > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake> > -- +1 919 869 8849
-- 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
