Niall Douglas wrote:
So, you're looking for the stacktrace and frame classes to not provide implementations of those member functions which rely on windows.h?
I assume you then want an additional header file e.g. "stacktrace_extra.hpp" which provides implementations for those?
Something like that. There are three possible ways to do it, and I haven't yet settled on one, or I'd have issued a pull request, as Antony asked. 1. #include "stacktrace.hpp" // as today, includes everything #include "stacktrace_def.hpp" // stacktrace without op<< or to_string In header-only libraries that don't use op<< or to_string, include the second header instead of the first. 2. #include "stackrace/stacktrace.hpp" // without op<< or to_string #include "stacktrace/output.hpp" // op<<, to_string Straightforward split into two headers, the difference is only that you need to explicitly include output.hpp for op<<. 3. #include "stacktrace.hpp" // declarations of everything, no definitions, no windows.h/COM #define BOOST_STACKTRACE_IMPLEMENTATION #include "stacktrace.hpp" // definitions, using windows.h, COM The usual way of packaging a non-header-only library in headers. The user defines BOOST_STACKTRACE_IMPLEMENTATION in one and only one .cpp file. No BOOST_STACKTRACE_LINK macro is necessary - if you link with the library, you just don't need to do the aforementioned. At the moment, I tend towards the third alternative, because it's a known practice and replaces the already existing BOOST_STRACKTRACE_LINK mechanism, so it doesn't introduce additional configuration complexity. Ideally, in (3), if you don't use op<< or to_string (or frame::name and so on), you won't need to include the implementation. So if you use a header-only library that includes stack traces in its exceptions, but you ignore these stack traces because you know nothing about the stacktrace library and don't use it, you won't have to pay the price if linking/including the implementation. In implementation terms, this_thread_frames::collect will have to be header-only so that the stacktrace constructors do not trigger link errors, the rest not.