Re: [boost] [Stacktrace] Review Manager report

Subject: Re: [boost] [Stacktrace] Review Manager report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-01-02 11:40:31

On 01/02/17 19:14, Niall Douglas wrote:
>
> From the reviews, I think there is consensus that the minimum viable
> product is achieved in Stacktrace though many mentioned that
> improvements are needed to the documentation and most of the negative
> feedback was on features not in the minimum viable product described
> above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace
> into Boost with the following conditions:
>
> 1. That the documentation more clearly set out what Stacktrace does and
> especially does not do, and that the default facilities provided are
> those of the Minimum Viable Product described above i.e. no source file
> nor line number discovery, no external dependencies on libraries not
> always provided on the target platform, no invocation of child
> processes, no async safety during stacktrace parsing. Stacktrace ought
> to be pared back to the minimum viable product featureset with no
> external dependencies at all.
>
> 2. That suitable predefined macros opt in to additional functionality
> such as serialisation of offset translated backtraces, retrieval of
> source code path and line number etc. Enabling these may introduce
> dependencies on third party libraries not always present on a system
> such as libunwind, or on third party helper utilities such as addr2line.
> I would recommend that the APIs the use of which are dependent on such
> third party items are entirely compiled out of Stacktrace when the macro
> enabling them is not defined.
>
> 3. That the documentation describe ONLY the default minimum viable
> product functionality in its tutorial and quick start. All extra
> functionality enabled by macros is to be relocated into a separate
> documentation section away from the main documentation e.g.
> "Advanced/optional features".
>
> 4. That APIs made available only when a given macro has turned them on
> are documented as such in the API reference docs.

Thanks Niall for managing the review and congrats to Antony.

I have to say though that I really don't think that a macro-based 
solution is the right way to go when a policy based pure C++ solution is 
possible. Config macros tend to result in compatibility issues when 
defined differently in different areas of the application, and 
stacktraces have the potential of travelling long distances across the 
application code if attached to exceptions.