Gesendet: Montag, 07. Januar 2019 um 07:08 Uhr Von: "Gavin Lambert via Boost"
On 5/01/2019 00:03, mike wrote:
For that, the cmake file in libfoo has to - provide the target Boost::libfoo - attach the dependency information for Boost::libfoo - attach the proper include directory for Boost::libfoo - if necessary, build libfoo with whatever toolchain and compile flags the parent cmake project defines - if necessary, attach any necessary compile definitions to Boost::libfoo
Does this assume/require a direct git checkout of the individual modules (separate include directory per library) or can it also work with a release bundle (common include directory)?
Yes. I can imagine different ways how one could add on support for the release bundle, but I've not spend any time investigating or comparing those solutions. My gut feeling ist that this would Ideally be handled somehow by a cmake file in the boost root folder.
For a quick overview, I uploaded a picture of the boost dependency graph (code based on boostdep) that shows which libraries Have a cmake file in their root and which don't [1].
I note that there are some green nodes which have red dependencies. Presumably this means that the library has some CMake support but it may or may not support the suggested workflow?
Essentailly yes. Most of them are libraries that have added CMake support before I started my efforts and I believe most are focused on library development - not user consumation (e.g. gil, beast, hana?, yap?). There are 1-2 libraries however, where I or the library maintainer has deliberately or accidentially added a cmake file as part of the current effort, before all dependenceis adopted one (E.g. utility).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost