Build documentation during build-time, and add a bt-audio implementation #52
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The two changes aren't really related, but oh well, I don't want to open too many PRs.
Documentation is now built at build-time, using pod2man within Automake instead of a separate
build-mans.sh
. The built documentation that was committed has been removed, and*.1
added to the.gitignore
. The POD files were also moved to a new docs/ directory, to make it easier to find than contrib/man/.In addition, a bt-audio implementation was added. This should fix #13, however the manual page's description doesn't really tell me what it did. It seems like before it was using BlueZ 4's org.bluez.Audio.Connect, and I think org.bluez.Device1.Connect is the new version; this would explain why the workaround in #13 (comment) is so simple. It seems to work, since I can type
./src/bt-audio -c <devicename>
and audio from it will start playing on my laptop... is that the correct behaviour?If it is, then I wonder if it would make sense to remove bt-audio again and merge it into bt-device (maybe with a small wrapper for muscle-memory/scripts). It seems like BlueZ 4 has org.bluez.Input.Connect, and that sounds like something that would've ended up in org.bluez.Device1.Connect, meaning that bt-input would also be served by the common implementation. bt-serial seems a little trickier, having something to do with profiles? I don't have a way to test either of bt-input or bt-serial, so I don't know if what I'm saying makes any sense.
If you don't like anything here (e.g. moving manpages to doc/), let me know and I can probably remove it.