From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: pkg-config support Date: Wed, 30 Apr 2008 15:24:52 +0200 Message-ID: <87fxt3scez.fsf@ambire.localdomain> References: <87lk2xd5qp.fsf@gnu.org> <87r6cpf11e.fsf@ambire.localdomain> <87r6cna7gl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1209600335 3488 80.91.229.12 (1 May 2008 00:05:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2008 00:05:35 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu May 01 02:06:11 2008 connect(): Connection refused Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JrMJD-0002nq-MH for guile-devel@m.gmane.org; Thu, 01 May 2008 02:06:00 +0200 Original-Received: from localhost ([127.0.0.1]:54692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrMIW-0001Cm-Or for guile-devel@m.gmane.org; Wed, 30 Apr 2008 20:05:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JrCgf-0004gg-5g for guile-devel@gnu.org; Wed, 30 Apr 2008 09:49:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JrCgc-0004fq-Fl for guile-devel@gnu.org; Wed, 30 Apr 2008 09:49:31 -0400 Original-Received: from [199.232.76.173] (port=58565 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrCga-0004fl-Qg for guile-devel@gnu.org; Wed, 30 Apr 2008 09:49:29 -0400 Original-Received: from [151.61.140.34] (helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JrCgV-00049L-M1; Wed, 30 Apr 2008 09:49:24 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1JrCIn-0001Y8-9U; Wed, 30 Apr 2008 15:24:53 +0200 In-Reply-To: <87r6cna7gl.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Wed, 30 Apr 2008 13:49:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-Greylist: delayed 1296 seconds by postgrey-1.27 at monty-python; Wed, 30 Apr 2008 09:49:23 EDT X-Mailman-Approved-At: Wed, 30 Apr 2008 20:05:14 -0400 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7200 Archived-At: () ludo@gnu.org (Ludovic Court=C3=A8s) () Wed, 30 Apr 2008 13:49:14 +0200 Having a package that installs its modules to $(GUILE_SITE) instead of $prefix/something is Bad(tm) as it breaks user expectations and the GCS (see "Variables for Installation Directories") I guess i will disagree on user expectations. I'm a (strange, granted) user and when i install Emacs Lisp, i expect there to be a `lispdir' (with defaults under Emacs' tree, but customizable, of course), and likewise for both .scm and .so files, under GUILE_SITE and GUILE_LIBSITE, respectively. This is because Emacs advertizes its "site" directory and nicely handles third-party files installed there. Likewise Guile w/ its "site". In Guile 1.4.x (and, as you may know, also for Guile 1.6.x), specially crafted shared object files somewhere under %load-path (either "site" or "libsite") can be handled just as well as scheme files, w/o any libtool hassles. So, having used these facilities, i expect them and welcome macros like GUILE_SITE and GUILE_LIBSITE that make the process easier. Probably the GCS should be extended to encourage use of these (then inclusion in Autoconf will be a side-effect). and it makes it impossible to run `distcheck' anyway. Could you please explain this (or point me to some relevant docs)? Thus many packages end up having their own `--with-guilemoduledir' option or similar that determines the installation directory of Guile modules and defaults to $prefix/something. This sounds like an argument for including GUILE_SITE and GUILE_LIBSITE. Am i misunderstanding you? As for libraries, there's an additional problem. Libraries that are not meant to be used from C (e.g., bindings of some C library whose C API is not public) would better fit under $pkglibdir than under $libdir. Sure. Private libraries should not be installed under GUILE_LIBSITE. That's not under discussion. In that case, the `.scm' module that calls `load-extension' must contain the full path to the lib, since it cannot expect it to be in ld.so's search path. The problem is that doing so precludes running tests from the build tree, before installation. (This is another instance of the problem that Libtool has with `RPATH', where the `RPATH' in the build tree must be different from the one in the installed library, so that the in-tree library can be used for testing purposes before installation. Libtool solves it by rebuilding the library with the right `RPATH' at "make install" time.) I sympathize w/ the `load-extension' difficulties, but don't experience them, personally. Guile 1.4.x treats (certain) shared object libraries as first-class modules, using "module catalogs" to locate a particular module. This builds on capabilities that were dropped after Guile 1.6.x (IIUC). Perhaps those can be brought back. The end result is that i do "make check" all the time using pre-installed modules. No Big Deal. Libtool is nice, but i've discovered that having Guile answer the "where is it on the filesystem?" question is nicer. IMO what we really need is: 1. Autoconf support for, say, `--guilemoduledir', so that Guile packages can use it consistently; For Autoconf to adopt something, it helps our case if that something exists and is in use, first. It's backwards to expect a good-fitting standardization effort to come from Autoconf. 2. Automake support to somehow solve the above problem with the path passed to `load-extension'. Good luck w/ that! I've been happy w/o `load-extension'; IMHO the sooner you let go of its approach the sooner you can be happy w/o it, too. thi