Add support for choosing between native-tls and rustls-tls backends
through feature flags, with native-tls as the default for maximum
platform compatibility.
Key changes:
- Add mutually exclusive native-tls and rustls-tls feature flags
- Use conditional compilation to select TLS implementation
- Configure rustls-tls with platform certificate verifier
- Refactor to workspace-based dependency management
- Update CI workflows with improved cross-compilation support
- Add comprehensive TLS backend documentation
The native-tls backend uses system TLS libraries (OpenSSL on Linux,
Secure Transport on macOS, SChannel on Windows) while rustls-tls
provides a pure Rust implementation with platform certificate stores.
- Update MSRV to 1.85 and Rust edition to 2024.
- Refactor all logging macros to use inline argument formatting.
- Fix import order in main.rs and examples.
- Add async environment variable setter to main.rs as safe facade.
- Update many dependencies to latest versions across all crates
- Switch from `once_cell::OnceCell` to `std::sync::OnceLock` where appropriate
- Update OAuth to use stateful `reqwest` for HTTP requests
- Fix Rodio backend to honor the requested sample format
On panic, the discovery task crashes, but the main program is not
notified of this. Returning an error will result in the Discovery stream
yielding None, serving as notification to the application (which might
shutdown with error, for example, if no other means of authentication is
available).
* discovery: use opaque error type for DnsSdError
This helps to decouple discovery and core by not leaking implementation
details of the zeroconf backend into Error conversion impls in core.
* discovery: map all MDNS/DNS-SD errors to DiscoveryError::DnsSdError
previously, libmdns errors would use a generic conversion
from std::io::Error to core::Error
* discovery: use an opaque type for the handle to the DNS-SD service
* discovery: make features additive
i.e. add with-libmdns instead of using not(with-dns-sd).
The logic is such that enabling with-dns-sd in addition to the default
with-libmdns will still end up using dns-sd, as before.
If only with-libmdns is enabled, that will be the default.
If none of the features is enabled, attempting to build a `Discovery`
will yield an error.
* discovery: add --zeroconf-backend CLI flag
* discovery: Add minimal Avahi zeroconf backend
* bump MSRV to 1.75
required by zbus >= 4
* discovery: ensure that server and dns-sd backend shutdown gracefully
Previously, on drop the the shutdown_tx/close_tx, it wasn't guaranteed
the corresponding tasks would continue to be polled until they actually
completed their shutdown.
Since dns_sd::Service is not Send and non-async, and because libmdns is
non-async, put them on their own threads.
* discovery: use a shared channel for server and zeroconf status messages
* discovery: add Avahi reconnection logic
This deals gracefully with the case where the Avahi daemon is restarted
or not running initially.
* discovery: allow running when compiled without zeroconf backend...
...but exit with an error if there's no way to authenticate
* better error messages for invalid options with no short flag
* added an option to specify ip addresses to which mDNS should bind (ignored by `DNS-SD`)
* changed command line option to `zeroconf-interface` to be consistent with `zeroconf-port`
use builder pattern to DRY up the code
used macro to print warning message
* fixing register error
* renamed `bind_ip` variables to match the option to `zeroconf_ip`, to be more consistent
* Changed user help
Modified comments
Added block for condition to clean the code
Added new modification to the change log
Co-authored-by: setime <timeframe1@gmx.de>
When librespot is built with Avahi turned on, it will crash if Avahi is
later not available at runtime.
This change avoids it crashing hard when Avahi is not available;
librespot will merely warn of the issue.
This affects some distribution packages too, where the maintainer might
prefer leaving Avahi support enabled, but many setups don't (or can't)
run Avahi.
Co-authored-by: Nick Steel <nick@nsteel.co.uk>
