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