Take headers and lib from pkg-config

[Asalle]

Currently we have hardcoded /usr/lib/roc path that is not always where you have your headers/lib. Let's take that info from pkg-config.

[gavv]

I've updated roc-streaming/roc-toolkit#271

[gavv]

.pc generation & installation landed in develop branch. scons install will now install roc.pc.

cc @fusuiyi123

[Asalle]

Yay! We can start using it in go bindings!

…

On Fri, May 15, 2020, 8:37 AM Victor Gaydov ***@***.***> wrote: .pc generation & installation landed in develop branch. scons install will now install roc.pc. cc @fusuiyi123 <https://github.com/fusuiyi123> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABF6TYTT6DIYXP66HGILXLDRRTPLFANCNFSM4JLIWN2Q> .

[Asalle]

now that I've looked into it, is this feature relevant? The only place where we use the C includes are comments like

/*
#include <roc/address.h>
*/
import "C"

which work regardless if one uses pkg-config or just installed them with their distribution's package manager.

[gavv]

If the user installed roc into a prefix which is not in default include or library search path list, compilation will fail. pkg-config will solve this issue.

A real-world examples. When you're using SoX library you should write:

#include <sox.h>

On most distros, sox.h is located at /usr/include/sox.h and include works without any pkg-config.

However, on some CentOS version, for some reason maintainers decided to install that file at /usr/include/sox/sox.h. On those CentOS systems pkg-config for SoX returns -I/usr/include/sox. If you're using pkg-config, everything works, but without it your include fails.

So yes, we still need pkg-config, though it's not critical.

Note that pkg-config generation is currently available only in develop, while bindings are using master.

[gavv]

Example of using pkg-config with cgo: https://github.com/aam335/speexdsp/blob/master/speexdsp.go#L4

[Asalle]

cool, then I'll test it locally with develop, push to a branch and create a pr later when the changes will be available on master (they are still not there as of now)

[gavv]

We'll also need to migrate bindings to new api from 0.2.

[gavv]

I guess we need a separate issue and branch for that.

[Asalle]

@gavv did you release 0.2 already? cannot find it anywhere

[gavv]

@Asalle Hi, no, 0.2 isn't released yet. It's still in the develop branch. The API of 0.2 is mostly stabilized; it will be changed a bit before final release, but I expect only minor changes. So I think we can start migration of bindings to 0.2, maybe in a separate branch (maybe also call it develop for convenience).