On Wed, 4 Nov 2015, Christophe Fergeau wrote: > Can you explain in the commit log why this is a good thing/why you need > to do that? Not sure how to explain it in the commit log. It's essentially like the video decoder support: we don't force the developer to choose between the builtin MJPEG decoder and the GStreamer decoder. You can compile both in and one can serve as the fallback for the other. I see no reason why it would be different for the audio backend. Of course, ideally all such cases should be able to pick the backend from the command line, a configuration file, and through the GUI. Also the PulseAudio / GStreamer libraries should be loaded dynamically to not force bringing in dependencies users may not care about. But I think that's best left for later. Another reason for the change is that the SPICE_CHECK_GSTREAMER() autoconf macro I introduce in the following patch defines 'HAVE_XXX' macros instead of the WITH_PULSEAUDIO / WITH_GST macros that were used. I also think having 'WITH_XXX' C macros is wrong as this essentially means the C code to depends on whether autoconf takes a --with-xxx or --enable-xxx option. Any optional features should depend on HAVE_XXX macros regardless of whether that's from a regular compatibility check, an --enable-xxx option or a --with-xxx one. -- Francois Gouget <fgouget@xxxxxxxxxxxxxxx> _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel