From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:35093)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QLwYy-0000jc-PP
	for qemu-devel@nongnu.org; Mon, 16 May 2011 08:06:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QLwYx-0006ad-Pu
	for qemu-devel@nongnu.org; Mon, 16 May 2011 08:06:16 -0400
Received: from mx1.redhat.com ([209.132.183.28]:61435)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QLwYx-0006aZ-Gy
	for qemu-devel@nongnu.org; Mon, 16 May 2011 08:06:15 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4GC6EGx022821
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Mon, 16 May 2011 08:06:14 -0400
Message-ID: <4DD11333.6020908@redhat.com>
Date: Mon, 16 May 2011 14:06:11 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1305474018-23235-1-git-send-email-alevy@redhat.com>	<1305474018-23235-3-git-send-email-alevy@redhat.com>	<4DD0CB7A.7050700@redhat.com>	<20110516102529.GF27965@playa.redhat.com>
	<4DD0FD3C.20707@redhat.com>
In-Reply-To: <4DD0FD3C.20707@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 2/2] libcacard: add libcacard.la target
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org

   Hi,

> Usually programs that are fully autoconf-iscated will ship a subset of
> libtool sources in the tarball, build a custom version at configure
> time, and invoke it from the Makefile via ./libtool. This has the
> advantage that only the maintainer needs to have libtool installed. OTOH
> we do not use Autoconf and I think this contributes to 99% of the bad
> name for Autoconf, so it's not something we want.

Another option would be to not use autoconf at all.  Building ELF shared 
libs isn't that difficuilt these days.  Question is whenever there is 
any non-ELF platform we care about (Windows maybe?).

cheers,
   Gerd