Distributing reusable code as a library is usually advantageous because
- it is fewer files for the consumer to wrangle (just one library file and one header at the minimum)
- it is faster to compile, because it's already compiled, so the consumer's compiler does not need to recompile it ever
- it means you are not exposing your source code directly, which is advantageous if you don't want consumers to have direct access to the code for whatever reason
Naturally you can eliminate these advantages if you handle the building and distribution of the library poorly (such as not collapsing your public headers to as few files as possible), and some of these advantages may not matter to you (maybe your project is open source, so keeping the code private is not a concern). Yes, consumers do need to configure library and header search paths, but that's generally assumed to be a basic cost-of-doing-business and isn't really that much harder than adding multiple external source files to a project.
Just distributing the source directly means you don't have to deal with all the various build configurations needed to ship the appropriate variants of the library for all supported platforms, so that's more advantageous to you. However you are sometimes taking that savings at the expense of advantages for the user (or at least, at the cost of creating potential disadvantages). For example, if your code doesn't compile cleanly on a client's machine because they used a stricter warning level, that's now something they have to manage or work around themselves.
Generally I find source-only distribution to be worthwhile if you have a single-header or maybe a single-header/single-source pair. But generally if there's more than one file involved, or any source files, I'd prefer a library and will usually build such source-only projects into a library myself before linking them with any of my projects.
