AMDG On 10/12/2018 09:00 PM, Peter Dimov via Boost wrote:
I've taken another stab at installing CMake configuration files along with the libraries in `b2 install`. CMake configuration files are .cmake files, typically installed into $prefix/lib or $prefix/lib/cmake, that allow f.ex. `find_package(boost_system)` in a CMakeLists.txt file to find the installed Boost.System library and declare a CMake target Boost::system that refers to it. CMake targets can then link to Boost::system and all is well.
Just a couple comments: * If generate-cmake-config takes the library as a source, then it's possible to derive both the library dependencies and the exact library name from the library target. The dependencies can be found at the virtual target level in generate-cmake-config, and the exact file name will appear as the source in generate-cmake-config-. Doing it this way also has the side effect that the CMake configuration won't be installed if the library fails to build, which may be a good thing. * I'm not fond of the ROOT parameter for boost-install.boost-install. * Dependencies can be referenced with /boost/$(deps)//[stage|install] * You can find the full path to the boost-install.jam with [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ] This avoids hard-coding the location of boost_install relative to the superproject. * That just leaves the stage directory, which is tied to the project root, and should perhaps be calculated in Jamroot instead of in boost_install. * This seems to handle --layout=versioned, but I'm not clear on how well it handles --layout=system where we expect to use a single compiled library for all configurations. * Are the error messages that you get from CMake when there isn't a configuration that matches the request intelligible? It looks like the target will exist but will silently do nothing? What if something goes wrong and there are multiple matches?
The work in its current state is available on the feature/cmake-config branch of the superproject:
In Christ, Steven Watanabe