From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: pkg-config support for guile Date: 23 Apr 2003 17:22:19 -0400 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87of50tdcz.fsf@raven.i.defaultvalue.org> <873cmbpyij.fsf@raven.i.defaultvalue.org> <87y937j7vq.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1051133612 28455 80.91.224.249 (23 Apr 2003 21:33:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Apr 2003 21:33:32 +0000 (UTC) Cc: Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 23 23:33:30 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 198Rru-0007Om-00 for ; Wed, 23 Apr 2003 23:33:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 198Rib-0006ce-03 for guile-devel@m.gmane.org; Wed, 23 Apr 2003 17:23:53 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 198Ri8-0006Z2-00 for guile-devel@gnu.org; Wed, 23 Apr 2003 17:23:24 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 198Rhw-0006Sa-00 for guile-devel@gnu.org; Wed, 23 Apr 2003 17:23:13 -0400 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 198RhD-00063U-00 for guile-devel@gnu.org; Wed, 23 Apr 2003 17:22:27 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id C5AF623FE; Wed, 23 Apr 2003 17:22:19 -0400 (EDT) Original-To: Marius Vollmer In-Reply-To: <87y937j7vq.fsf@zagadka.ping.de> Original-Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2198 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2198 [I sent a patch to add pkg-config support.] I don't think we should offer two ways to get configuration information about Guile. When pkgconfig is better than our current method, we should use it exclusively. When not, we should keep our current stuff. pkgconfig is better in that programs that use guile will not have to include a guile-specific m4 fragment into configure - there is a standard pkgconfig m4 fragment that suffices to link all programs that use pkgconfig for config info. But programs needing GUILE_MODULE_FOO will still need the guile m4. This is really a separate problem from guile-config - using guile as a scripting language rather than a libary, so not trying to use pkgconfig here seems fine. I don't understand why you think there should not be two ways. Users can use whichever way they like better, and this makes guile more friendly. Over time, I expect pkg-config to be more prevalent. The pkg-config support is very small, and most of the contents are substituted via configure. So having two ways is a reasonable transition strategy. (When I say "we should use pkgconfig exclusively", I mean we should use it to re-implement guile-config in a compatible way. We should definitely continue to offer the guile-config interface.) Sure, the old interface should be retained. But the real win comes from people being able to just write a simple line to include the library that is similar to how many other libraries are included. I have a line in some of my own (unpublished so far) sources that reads: PKG_CHECK_MODULES(FOO, libfoo, AC_DEFINE(HAVE_LIBFOO), true) The final 'true' prevents an error if the package is not found. > The file won't be useful without pkg-config installed, of course, > but this gives users a choice of configuration means. Why would they need this choice? [genuine question(tm)] Well, it seems the world is heading to a standardized method of representing how to link with libraries (and handling recursive dependencies, so linking with gtk gets you glib without explicitly asking for it). I view this as an abstraction of using libraries with autoconf, and it's really only better because it implements a well-defined interface instead of the ad-hoc sort-of-like-other-packages homegrown one in guile. The only downside is that the pkgconfig way requires that pkgconfig be installed on systems where one links with pkgconfigized libraries. pkgconfig is installed on most systems, since both the gnome and kde worlds need it. Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel