Include path fix for opus_multistream.h

[ienapliss]

trafficstars

Why should you force the end user to include Yet Another Unnecessary Include Path in their project when it is possible to avoid it.

# include <opus_multistream.h>

to

# include <opus/opus_multistream.h>

Thank you.

See also: https://github.com/xiph/opusfile/issues/10 https://github.com/xiph/opusfile/pull/20

[braindigitalis]

any movement on this? its causing grief with our CI

[braindigitalis]

ive written a PR for this #47 hopefully it will get merged.

The justification that this is the way it is supposed to work is false, because directly above the erroring line is:

# include <ogg/ogg.h>

If it was the case we were expected to add /usr/include/libraryname for every dependent lib to our includes, why isnt this <ogg.h>?

[rubyFeedback]

I am quite certain the original explanation given be one dev is simply wrong here. The behaviour displayed by opusfile is not correct; I just ran into this issue with regards to SDL2_mixer. I did update all files via findutils and I can not find any file called opus_multistream.h. Right now I have no idea who is supposed to install the file, but whoever is ASSUMED to do so, doesn't do so, which causes problems. I haven't yet done a google search where opus_multistream.h can be found - interestingly, on my local filesystem, SDL2_mixer insists on having it:

/home/x/Temp/rbt/SDL2_mixer-2.8.0/VisualC/external/include/opus/opus_multistream.h

Which is very confusing to me. Why is that one in VisualC? That sounds windows-related. Perhaps SDL2_mixer is also wrong. Either way, as this assumes to belong to "opus", opus should consider the issue here.

Edit: I may have gotten the names wrong too. On my local system I have:

libopusenc, opus, opusfile and opustools.

Would be nice if these could all be merged into one-opus-to-rule-them-all really.