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
CMake itself.
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
shlibs.
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.
Regards,
Roger