From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: doc libdir and C code modules Date: Sat, 04 Feb 2006 11:28:49 +1100 Message-ID: <87zml86k72.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1139018019 22146 80.91.229.2 (4 Feb 2006 01:53:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 4 Feb 2006 01:53:39 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 04 02:53:36 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F5CcI-0007HM-FC for guile-devel@m.gmane.org; Sat, 04 Feb 2006 02:53:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F5CfU-00064j-Oy for guile-devel@m.gmane.org; Fri, 03 Feb 2006 20:56:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F5BLh-0005n2-Vz for guile-devel@gnu.org; Fri, 03 Feb 2006 19:32:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F5BLd-0005gk-Rm for guile-devel@gnu.org; Fri, 03 Feb 2006 19:32:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F5BLc-0005fM-Sj for guile-devel@gnu.org; Fri, 03 Feb 2006 19:32:17 -0500 Original-Received: from [61.8.0.84] (helo=mailout1.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F5BKh-0001Wk-Ki for guile-devel@gnu.org; Fri, 03 Feb 2006 19:31:20 -0500 Original-Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k140SrTi011431 for ; Sat, 4 Feb 2006 11:28:54 +1100 Original-Received: from localhost (ppp2CA4.dyn.pacific.net.au [61.8.44.164]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k140SqKc006920 for ; Sat, 4 Feb 2006 11:28:52 +1100 Original-Received: from gg by localhost with local (Exim 3.36 #1 (Debian)) id 1F5BIH-0002K9-00; Sat, 04 Feb 2006 11:28:49 +1100 Original-To: guile-devel@gnu.org Mail-Copies-To: never User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) 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:5651 Archived-At: I added the words below to the manual as the last subsection in "Dynamic Libraries", to encourage packages to use libdir. I don't want to re-open the can of worms about versioning and stuff, this is intended just to describe the present situation. 5.16.4.4 Compiled Code Installation ................................... The simplest way to write a module using compiled C code is (define-module (foo bar)) (load-extension "foobar-c-code" "foo_bar_init") When loaded with `(use-modules (foo bar))', the `load-extension' call looks for the `foobar-c-code.so' object file in the standard system locations, such as `/usr/lib' or `/usr/local/lib'. If someone installs your module to a non-standard location then the object file won't be found. You can address this by inserting the install location in the `foo/bar.scm' file. This is convenient for the user and also guarantees the intended object file is read, even if stray older or newer versions are in the loader's path. The usual way to specify an install location is with a `prefix' at the configure stage, for instance `./configure prefix=/opt' results in library object code like `foobar-c-code.so' going under `/opt/lib/foobar-c-code.so'. When using Autoconf (*note Introduction: (autoconf)Top.), the library location is in a `libdir' variable and it can be inserted automatically by writing the scheme code as a `bar.scm.in', (define-module (foo bar)) (load-extension "@libdir@/foobar-c-code" "foo_bar_init") The Autoconf manual describes how this is processed to make the actual `bar.scm' which is installed (*note Creating Configuration Files: (autoconf)Configuration Files.). A substitution can also be done explicitly in a `Makefile' with a simple `sed' (*note Introduction: (sed)Top. A Stream Editor). If several modules need this, it can be easier to create one `foo/config.scm' with a define of the `libdir' location, and use that as required. (define-module (foo config)) (define-public foo-config-libdir "@libdir@"") Such a file might have other locations too, for instance a configured data directory for auxiliary files, or `localedir' if the module has its own `gettext' message catalogue (*note Internationalization::). When installing multiple C code objects, it can be convenient to put them in a subdirectory of `libdir', thus giving for example `/usr/lib/foo/some-obj.so'. If the objects are only meant to be used through the module, then a subdirectory keeps them out of sight. It will be noted all of the above requires that the Scheme code modules can be found in `%load-path' (*note Build Config::). Presently it's left up to the system administrator or each user to augment that path when installing Guile modules in non-default locations. But having reached the Scheme code, that code should take care of hitting any of its own private files etc. Presently there's no convention for having a Guile version number in module C code filenames or directories. This is primarily because there's no established principles for two versions of Guile to be installed under the same prefix (eg. two both under `/usr'). Assuming upward compatibility is maintained then this should be unnecessary, and if compatibility is not maintained then it's highly likely a package will need to be revisited anyway. The present suggestion is that modules should assume when they're installed under a particular `prefix' that there's a single version of Guile there, and the `guile-config' at build time has the necessary information about it. C code or Scheme code might adapt itself accordingly (allowing for features not available in an older version for instance). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel