nmos-cpp: Add new version, cleanup and support macOS

[irieger]

Summary

Changes to recipe: nmos-cpp/various

Motivation

• Current version in CCI is around 18 months old and there have been a lot of changes
  • Large change for me is the support of macOS now upstream, which is implemented to be allowed for the newest version.

Details

Sadly no official releases yet so doing a cci.xyz release. https://github.com/sony/nmos-cpp, quite a few fixes, like very visibly in the macOS support but also small other MRs.

Took the liberty to remove the 2022 versions and clean out the patches and some workarounds needed for those as well as removing the conan 1 properties to make it a bit cleaner overall.

---

• Read the contributing guidelines
• Checked that this PR is not a duplicate: list of PRs by recipe
• Tested locally with at least one configuration using a recent version of Conan

[irieger]

Suggested change

	# Simple change as github doesn't allow review comments on unchanged lines that are outside the +/- 3 lines of the changes.
	# To be removed in the review process.
	if self.settings.os == "Macos":
	if self.settings.os == "Macos":

Comment just temporary to get the possibility of doing comments in this review tool here which didn't allow it despite unfolding unchanged lines.

[irieger]

Suggested change

	del self.options.with_dnssd
	# The removal on macos makes sense as the mdnsresponder (which is by apple) comes with the OS/Xcode SDK I guess,
	# but why override the default. Took me (luckily only a few minutes) time to see why it wanted to get avahi despite the default_options and like thousands of
	# dependencies. mdnsresponder is just itself, avahi really has a large sets of dependencies and many of them LGPL infested...
	# Also getting the `conan graph info ... --format=html` for avahi and mdnsresponder and opening both in the browser is eye-opening. If there is a reason
	# why mdnsresponder isn't cutting it, would be nice to be noted. I'd prefer it with the two elif cases removed to have some consistency.
	elif self.settings.os == "Linux":
	self.options.with_dnssd = "avahi"
	elif self.settings.os == "Windows":
	self.options.with_dnssd = "mdnsresponder"
	# a last one to being able to github this ...
	del self.options.with_dnssd

So I wonder why not to remove this or what the reason is for that.

Maybe @garethsb could give some input why there is an override of the defaults. If there is a good reason, I think it should be documented (and I'd happily add that, here, where the override happens and with a short comment in the default_options so that others don't need to wonder why despite the default avahi is pulled).

Otherwise maybe @jonathan-r-thorpe or @lo-simon who seem to be main contributors to nmos-cpp can comment?

[garethsb]

Hi @irieger, and thanks for working on this.

Macos build has been possible for a very long time, but we had some problems with it in the conan-center-index CI infrastructure, so agreed to disable it in the recipe. See #14152 (comment). If the build is now successful and the binaries work for people (note that at CCI maintainers request, the test package no longer actually tests that, which it did at the point that we disabled Macos), then very happy to have it reinstated.

The rationale for the Avahi vs mDNSResponder differences is:

• it doesn't make sense to use Avahi on Macos, or even build mDNSResponder, since it's always present on Mac
• Windows has had a stable but flawed mDNSResponder implementation as a Windows service available from Apple for a really long time, whereas Avahi is not commonly used
• on Linux, Avahi is much more commonly used than mDNSResponder, so it makes sense as the default simply from that point of view

There are a number of pros and cons to both libraries, with bugs or missing features that affect NMOS, such as support for over-long service types, handling of multiple interfaces, advertising alias hostnames, resolving hostnames to multiple IP addresses, support for unicast DNS-SD, ... Some of these are documented in nmos-cpp repo.

Finally, I recommend we get advice from @jonathan-r-thorpe and @lo-simon of which date/commit hash for this release.

[irieger]

Hi @garethsb

thanks for the answer.

Macos build has been possible for a very long time, but we had some problems with it in the conan-center-index CI infrastructure, so agreed to disable it in the recipe. See #14152 (comment). If the build is now successful and the binaries work for people (note that at CCI maintainers request, the test package no longer actually tests that, which it did at the point that we disabled Macos), then very happy to have it reinstated.

I just had the nmos-cpp-node running on my MacBook to connect to the easy-nmos docker registry so I guess at least that part is working. Haven't tested more.

The rationale for the Avahi vs mDNSResponder differences is:

* it doesn't make sense to use Avahi on Macos, or even build mDNSResponder, since it's always present on Mac

* Windows has had a stable but flawed mDNSResponder implementation as a Windows service available from Apple for a really long time, whereas Avahi is not commonly used

* on Linux, Avahi is much more commonly used than mDNSResponder, so it makes sense as the default simply from that point of view

Ok, get it. Thanks for the explanation. Maybe I'll have another look, but it feels like having a default 'auto' option would be nice. That would be much cleaner than having a default that is overriden anyway and confuses the user why suddenly the selected option (default) is ignored. So idea is:

• auto: Use the default as currently done: Use system mDNS on macOS, mDNSResponder on Windows and avahi on Linux
• mdnsresponder: Use mdnsresponder on Win/Linux, maybe configuration error on macOS or does that not make sense?
• avahi: Use avahi on Linux. Not sure about Win, configuration error on macOS?

I'll try this in the evening and also test the client with mdnsresponder on Linux against the registry.

Finally, I recommend we get advice from @jonathan-r-thorpe and @lo-simon of which date/commit hash for this release.

Would be nice to get some feedback there, sure.