Re: [boost] Boost CMake support - Request for Comment

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