Re: [boost] [cmake] Pull request announcement - update

Subject: Re: [boost] [cmake] Pull request announcement - update
From: jeff_at_[hidden]
Date: 2019-01-04 12:39:25

Awesome work Mike.  Love the graphic too

-----Original Message-----
From: Boost <boost-bounces_at_[hidden]> On Behalf Of mike via Boost
Sent: Friday, January 4, 2019 4:03 AM
To: boost_at_[hidden]
Cc: mike.dev_at_[hidden]
Subject: [boost] [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.

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost