Subject: Re: [boost] Boost CMake support - Request for Comment
From: Roger Leigh (rleigh_at_[hidden])
Date: 2018-10-10 08:24:49
On 09/10/2018 23:08, Andrey Semashev via Boost wrote:
>> Library Test
>> Should facilities for "testing" be only done by developers? or should
>> users who acquire library packages also be able to test libraries.
> I think, the ability to test libraries is essential for both Boost
> developers and users (primarily, developers, though). I think,
> potential solutions should include this functionality.
>> Should CMake testing results posting be used - CDASH?
> I don't really know what CDash is, I've never used it.
It's a "dashboard" which displays submitted test results. It can be
used to aggregate testing on multiple platforms.
https://open.cdash.org/index.php?project=CMake is the dashboard for
Boost could potentially use it, either the open dashboard or a
self-hosted one, but it's strictly optional. Maybe Travis is
sufficient, or you could integrate something else entirely.
>> Library Packaging
>> Is the library packaging facility provide by CMake - CPACK - useful to
>> boost. Should boost libraries be updated to support it?
> I would really like us to not get into the packaging business beyond
> preparing source packages of Boost releases. Packaging is a difficult
> topic, very target system dependent. Let the people who has the domain
> knowledge do it.
> As someone who has built Debian packages of Boost for my project I can
> tell that it is unlikely that I would use CPack. Not because something
> is wrong with it (in fact, I've never had to use it, so I really don't
> know), but because the current building pipeline doesn't involve it
> and works backwards.
Last time I tried it, it was inferior to the native packaging tools.
Particularly when packaging libraries, it didn't do as good a job with
library version dependencies--if you build Debian packages on a
non-Debian platform it can't compute the minimum library version from
I think it's primarily useful for packaging standalone applications
where there are no complex library dependencies. Certainly for Windows
and MacOS X it makes sense. For packaging a set of libraries like
Boost, I don't think it's as useful; we already have good Boost
packaging anyway, so I'd suggest ignoring it at least for now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk