On Sat, Oct 1, 2016 at 8:58 PM, Paul Fultz II
Well, cmake should install the library, even its header-only. It should also provide cmake packaging and/or pkg-config to help with linking against the library and its dependencies. I do this in my libraries and could send you a pull request.
Uhh...err... okay, I have to admit - I've been a Windows user for quite a long time. And Windows was born with a handicap - there's no well defined place to put libraries and header files. So I'm behind the curve on having CMake "install" the library (what would that even mean for Windows?) But, its an interesting coincidence, someone already raised this point: https://github.com/vinniefalco/Beast/pull/98 If you want to submit a pull request for the install functionality, I think that would be great.
But I do wonder if it should be header-only. Is it that heavily templated that `.cpp` files don’t make sense?
Well, yes. The algorithms for serializing and parsing messages are generic, accepting any object that meets the type requirements. The WebSocket stream can wrap any object that meets the requirements. This lets the same code work both for plain connections and SSL connections. Or use your own socket class if you want. On a related point, header-only libraries are more convenient. They require less configuration and mostly "just work." The first thing people ask about non-header only libraries in a formal review is "Why isn't this header-only?"
As far as linking goes, you should only need Boost.System (for error_code).
Oh, so it doesn’t use Boost.Asio either?
It "uses" Boost.Asio, but since Asio is also header-only, there is nothing to link with. However, Boost.Asio also requires Boost.System for error_code (unless you fiddle with some macros). Thanks