There is conflicting (or perhaps unintentionally misleading/ambiguous?) documentation for the recommended include path of miniaudio headers. This has seemingly led into discrepancies in how distro and build system packagers are packaging your library as a system dependency, which makes it pretty frustrating to integrate into build systems without just vendoring the file in.

The first page of the manual states:

To use miniaudio, just include "miniaudio.h" like any other header and add "miniaudio.c" to your source tree.

...as such, Fedora's miniaudio-devel package and Debian's libminiaudio-dev bundle miniaudio in a way such that the include path for the library is:

#include <miniaudio.h>

...which matches the guidance on the first page of the manual. Meson's WrapDB and (I think) vcpkg similarly do this.

Unfortunately, the README seems to directly conflict with this paradigm:

This example shows one way to play a sound using the high level API.

#include "miniaudio/miniaudio.h"
// ...

This has caused Homebrew and Gentoo packagers (and perhaps more...) to instead follow the guidance of the README and nest the miniaudio include directory inside a miniaudio folder. This means that you cannot reliably pull in miniaudio headers from a system package manager and expect to build a project using it on all host machines (at least without vendoring the file in), which is pretty unfortunate.

Is there any guidance on how miniaudio should be included? Is it miniaudio.h or miniaudio/miniaudio.h? Who should I complain to in order to get this fixed? I understand that this is a single-header library and you probably intended people to just vendor in the file (at least based on the website's download button), but without guidance around a standard include path for this library, packagers are going to continue to mess this up.