[cmake] Pull request announcement - update
I think it is time for an update on this issue. #################################################### # TLDR: There are now ~25 boost libraries that can be directly used in a cmake project via the add_subdirectory & target_link_library - workflow. And I want to encourage library maintainers to comment/merge outstanding PRs or make similar additions to their libraries themselves. ################################################### # A summary what that thread was about: In September last year I was informing the mailing list that I was about to make a bunch of PRs adding a set of minimal CMake files to various boost libraries. Their sole purpose was to enable the following workflow from within a cmake project: add_subdirectory( <path-to-boost-libfoo-directory> ) target_link_library( my_app Boost::libfoo ) Without needing b2 or the boost super project for that matter (although support in the super project would be very welcomed) 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 Although things like running the unit-tests or provide and install target can be added by any library maintainer (and some have done just that) it is not part of my PRs. ################################################### # What is the current state. 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]. So far, about 25 libraries have gained cmake files as part of this effort (not all from me). And of course there are a couple of libraries that Already used cmake before I started my efforts, but AFAIK, most of them can not be used in the above mentioned work-flow. Of course, there remains a lot to do, but at least progress is happening and we now have fitted almost all "foundational" libraries , so from here on out, the pace should increase. Currently, I have 7 outstanding PRs and I would ask the Respective maintainers to comment on them as soon as they can find some spare time, as further PRs are blocked on them. Even if the PRs get completely rejected, I at least know for which part of boost I should no longer pursue this quest and/or find a workaround. Finally a big thanks to all maintainers that added such cmake files on their own. Best Mike [1] https://gist.github.com/Mike-Devel/46d04409d6ae6053861706e3ad91e4dc Explanation for the linked picture: It shows the boost dependency graph (generating code based on boostdep). - Green libs already have a cmake file in their root directory - Yellow libraries don't have such a cmake file, but all their dependencies have one, so one could be added and most likely there is already a PR for that - Red libraries have at least one direct or indirect Dependency that lacks a cmake file, so I consider Them "blocked" for now.
Awesome work Mike. Love the graphic too
-----Original Message-----
From: 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)?
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?
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
participants (4)
-
Gavin Lambert -
jeff＠22ndtech.com -
Mike -
mike.dev＠gmx.de