From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [RFC] modular dependencies for kvm's qemu Date: Tue, 16 Oct 2007 14:39:30 +0100 Message-ID: <20071016133930.GB2107@redhat.com> References: <20071016092214.GA13850@tapir> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Carlo Marcelo Arenas Belon Return-path: Content-Disposition: inline In-Reply-To: <20071016092214.GA13850@tapir> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Tue, Oct 16, 2007 at 04:22:14AM -0500, Carlo Marcelo Arenas Belon wrote: > Greetings, > > kvm's configure calls qemu's configure with --enable-alsa, making the > existence and use of alsa a dependency; with the import of the latest CVS > qemu, a similar implicit dependency has been added for gnutls (required for > TLS support for qemu's vnc server). > > the following proposed patch (which is a combined patch from a 2 patch series) > allows kvm's configure to enable alsa or disable vnc tls conditionally. > > I am curious if the approach taken for alsa (which is the one that fits what > qemu's configure allows for this case) is acceptable or not, as it will change > the dependency on alsa from being required by default to optional and unless > --enable-alsa is used. So why don't you use --disable-alsa in the patch instead. It seems like rather a bad idea to suddenly switch the configure script defaults in the way you suggest for alsa. It really wouldn't be much harder to set enable_alsa=1 in the top of configure, and then have the flag toggle it to off. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/