Re: [boost] Boost Cmake Modules

Subject: Re: [boost] Boost Cmake Modules
From: paul (pfultz2_at_[hidden])
Date: 2017-01-12 14:44:32

On Thu, 2017-01-12 at 15:19 +0000, Niall Douglas wrote:
> > 
> > So does anyone have any feedback on this setup? If you had ideas,
> > or
> > would like to help update boost libraries, contributions are
> > welcome.
> Given the other reply to this describing their boost cmake design, I
> guess I'd better mention boost-lite's:
> 
> * 100% cmake3 based (and uses "modern cmake" throughout) with no
> other
> tooling needed

These modules are cmake 3 based as well, without a need for extra
tooling either.

> * Autodiscovers any library with the boost directory layout

The `bcm_boost_package` function does rely on the layout to add and
install headers, However, it doesn't for source files. I am concerned
about boost libraries conditionally adding sources for some platforms.
Also, some authors may not like globbing files(unless you found a way
to workaround this problem). Perhaps, it could glob the sources in lib,
by default, and then the author could override it with the `SOURCES`
arg.

> * Autodiscovers any tests you have and sets them up with ctest

This is interesting. But I don't think it scales. Some tests require
linking in multiple sources, or require certain flags to be enabled. I
really don't see how to autodiscover tests that will work for most
boost libraries. Perhaps a `bcm_auto_test` function could be called by
the author to do that(I would like to know what kind of conventions you
follow when discovering the tests), and for libraries that have more
complicated testing infastructure and add the tests manually with
`bcm_add_test`. 

> * Provides out of the box CI ctest scripting which uploads results to
> a
> CDash for your project and updates your github website with the
> output
> from doxygen

This is probably useful for libraries that use doxygen. Using sphinx or
mkdocs, I don't need to push changes out to github, as ReadTheDocs will
update the documentation on push. Plus it will store the documentation
for different tagged versions as well. This scales much nicer than
using github pages. I haven't added any support for documentation yet,
as the first support for documentation will need to be for the boost
documentation toolchain.

> * Automatically uses C++ Modules and precompiled headers where
> available
> * Automatically configures clang-tidy, asan, tsan, msan and ubsan
> sanitiser targets

Support for these things would be a nice addition. 

> * Automatically matches git SHA in dependent git subrepos in flat
> dependency configurations

I am not a fan of git submodules, as it breaks downloading the source
tarball files from github.

> * Automatically merges any develop commit passing all tests on all
> platforms according to CDash into master branch
> * Automatically packages up your library and publishes it to tarball,
> vcpkg (with ubuntu launchpad and homebrew in progress right now)

Adding support for CPack to create tarballs, debian, and fedora
packages would be nice to add. However, mapping dependecies names
between different package managers can be handled through convention
for boost-only libraries, however, external dependencies(such as zlib)
is not so easy. 

Also, as the library would support standard cmake install flow, it can
easily be installed with cget(and dependencies can be installed with a
requirements.txt file). I find this flow preferable over trying to
update system-level package managers like homebrew or vcpkg. Although,
from what I've seen from vcpkg, it works very similiar to cget except
it is windows-centric.

> * Libraries based on this are 100% standalone, when you clone the git
> repo or unpack the tarball you are 100% ready to go. Nothing else
> needed, not even configure and build. No arcane command line programs
> to
> run.

I don't understand this. My focus of these modules is to support the
standard configure, build and install flow in cmake. Trying to hack
cmake with a different conventional flow seems problematic. If users
don't like this flow, or scared of typing, then external tools can be
created to automate this. However, creating a different flow in cmake
will just cause a dissonance with other cmake libraries.

> * 99% compatible with VS2017's new cmake project support (I have some
> bugs to file with them). It's very close to working perfectly.
> 
> I wouldn't recommend that anyone else use it yet. It is very much a
> work
> in progress, but all the above is working, and you can see it in
> action
> in proposed Boost.Outcome. It also has nil documentation.

So I tried to install your Boost.Outcome library with no luck. First, I
did `cget install ned14/boost.outcome`. And that didn't work because of
missing the git submodules. So, I cloned it locally with its
submodules, and then did `cget install boost.outcome`. It still didn't
work.

However, it looks like you have done a lot of awesome work here, and it
would be great to integrate those into the cmake modules so other boost
libraries could take advantage of it.

Paul