Build rpm with .spec file; export bluealsa headers and libraries.

[Afeather2017]

I've did what the title said.

Add a spec script file to build a rpm.

And I do need to use headers to build my app, so I exported them.

[borine]

There was a PR (#95) raised many years ago for adding a distributable shared library to the build, and it was decided there that the D-Bus API was a more appropriate and stable way for clients to access the bluealsa service (from a compatibility perspective). Now I guess that the BlueALSA API is possibly less unstable than it was back then, but even so it still cannot be considered "stable".

The most important consideration that must be dealt with before it becomes appropriate to add a shared client library is that the BlueALSA ABI is certainly not stable, so to avoid a Linux equivalent of the Windows "DLL Hell" it is absolutely essential that the library has embedded within it ABI versioning metadata. For example, You could use libtool's library versioning feature (see https://www.gnu.org/software/libtool/manual/libtool.html#Library-interface-versions).

Also note the section "Tips for interface design" in that document: the code you are using was not designed for use in a shared library so you should check it against those tips and perhaps make some changes if necessary. If such changes are required then it may well impact other code throughout the bluez-alsa project, so do think hard whether the amount of effort required to do this properly is really worth it.

As for the .spec file, I personally do not like it. It is hand-written specifically for one version of BlueALSA, with one very specific set of configuration options. It even has an explicit list of files to be installed. That is a maintenance nightmare and will be applicable only to a very small subset of users who happen to need those configuration options. Note that neither bluez nor alsa-lib include rpm (or deb) build files; it is left up to each distribution to craft its own, according to its own standards, conventions and compatibility requirements.

[arkq]

As for the .spec file, I personally do not like it.

Yes, there was an issue or PR some time ago about adding deb setup here and I did not accept that because of the issue mentioned by @borine. I'm afraid that nothing has changed since then. I know that it might be inconvenient for some, but we can not have packaging setup for every possible Linux distro here (e.g. why have spec here and not e.g. ebuild? why one distro is "better" than other).

[Afeather2017]

Well, I've went through whole of the google result and try to find some way to build distribution packages with autotools, and found no result. They kept telling me to find out all the things it installed and all the commands it run. So I generate file list with make install DESTDIR=fake-root; find fake-root.
Because I did need to build a rpm, so I dealt with rpm. And I didn't know .spec very much, so I hand-written them. As for the shared library distribution, yeah, I've took less consideration.
Anyway, It's a helpful project, I appriciate all of you guys, so I leave this here to help someone who need this.
By the way, I found that we are able to build these distribution packages with serveral lines of code in cmake, meson etc.

[borine]

I've written a wiki page to help explain how to create clients using the D-Bus API without the need for any shared library in the bluez-alsa project: https://github.com/arkq/bluez-alsa/wiki/Using-the-BlueALSA-D%E2%80%90Bus-API

Of course if anyone wants to create their own shared libary, then the MIT license of bluez-alsa allows them to copy files from here to re-use in their own library, with minimal restrictions.