mirror/guile
mirror/guile
1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-05-20 11:40:18 +02:00
Code Activity

(Compiled Code Installation): Revise, in particular

Browse source 
@libdir@ needs to go via the makefile.
This commit is contained in:
Kevin Ryde 2006-02-07 00:02:48 +00:00
parent 689596d425
commit 6cf755c27c
1 changed files with 31 additions and 28 deletions
Download patch file Download diff file Expand all files Collapse all files

59
doc/ref/api-modules.texi
View file

@ -1247,48 +1247,51 @@ The simplest way to write a module using compiled C code is
@end example @end example
When loaded with @code{(use-modules (foo bar))}, the When loaded with @code{(use-modules (foo bar))}, the
@code{load-extension} call looks for the @file{foobar-c-code.so} @code{load-extension} call looks for the @file{foobar-c-code.so} (etc)
object file in the standard system locations, such as @file{/usr/lib} object file in the standard system locations, such as @file{/usr/lib}
or @file{/usr/local/lib}. or @file{/usr/local/lib}.
If someone installs your module to a non-standard location then the 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 object file won't be found. You can address this by inserting the
install location in the @file{foo/bar.scm} file. This is convenient install location in the @file{foo/bar.scm} file. This is convenient
for the user and also guarantees the intended object file is read, for the user and also guarantees the intended object is read, even if
even if stray older or newer versions are in the loader's path. stray older or newer versions are in the loader's path.
The usual way to specify an install location is with a @code{prefix} The usual way to specify an install location is with a @code{prefix}
at the configure stage, for instance @samp{./configure prefix=/opt} at the configure stage, for instance @samp{./configure prefix=/opt}
results in library object code like @file{foobar-c-code.so} going results in library files as say @file{/opt/lib/foobar-c-code.so}.
under @file{/opt/lib/foobar-c-code.so}. When using Autoconf When using Autoconf (@pxref{Top, , Introduction, autoconf, The GNU
(@pxref{Top, , Introduction, autoconf, The GNU Autoconf Manual}), the Autoconf Manual}), the library location is in a @code{libdir}
library location is in a @code{libdir} variable and it can be inserted variable. Its value is intended to be expanded by @command{make}, and
automatically by writing the scheme code as a @file{bar.scm.in}, can by substituted into a source file like @file{foo.scm.in}
@example @example
(define-module (foo bar)) (define-module (foo bar))
(load-extension "@@libdir@@/foobar-c-code" "foo_bar_init") (load-extension "XXlibdirXX/foobar-c-code" "foo_bar_init")
@end example @end example
The Autoconf manual describes how this is processed to make the actual @noindent
@file{bar.scm} which is installed (@pxref{Configuration Files, , with the following in a @file{Makefile}, using @command{sed}
Creating Configuration Files, autoconf, The GNU Autoconf Manual}). A (@pxref{Top, , Introduction, sed, SED, A Stream Editor}),
substitution can also be done explicitly in a @file{Makefile} with a
simple @code{sed} (@pxref{Top, , Introduction, sed, SED, A Stream
Editor}).
If several modules need this, it can be easier to create one @example
@file{foo/config.scm} with a define of the @code{libdir} location, and foo.scm: foo.scm.in
use that as required. sed 's|XXlibdirXX|$(libdir)|' <foo.scm.in >foo.scm
@end example
The actual pattern @code{XXlibdirXX} is arbitrary, it's only something
which doesn't otherwise occur. If several modules need the value, it
can be easier to create one @file{foo/config.scm} with a define of the
@code{libdir} location, and use that as required.
@example @example
(define-module (foo config)) (define-module (foo config))
(define-public foo-config-libdir "@@libdir@@"") (define-public foo-config-libdir "XXlibdirXX"")
@end example @end example
Such a file might have other locations too, for instance a configured Such a file might have other locations too, for instance a data
data directory for auxiliary files, or @code{localedir} if the module directory for auxiliary files, or @code{localedir} if the module has
has its own @code{gettext} message catalogue its own @code{gettext} message catalogue
(@pxref{Internationalization}). (@pxref{Internationalization}).
When installing multiple C code objects, it can be convenient to put When installing multiple C code objects, it can be convenient to put
@ -1296,12 +1299,12 @@ them in a subdirectory of @code{libdir}, thus giving for example
@code{/usr/lib/foo/some-obj.so}. If the objects are only meant to be @code{/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. 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 It will be noted all of the above requires that the Scheme code to be
modules can be found in @code{%load-path} (@pxref{Build Config}). found in @code{%load-path} (@pxref{Build Config}). Presently it's
Presently it's left up to the system administrator or each user to left up to the system administrator or each user to augment that path
augment that path when installing Guile modules in non-default when installing Guile modules in non-default locations. But having
locations. But having reached the Scheme code, that code should take reached the Scheme code, that code should take care of hitting any of
care of hitting any of its own private files etc. its own private files etc.
Presently there's no convention for having a Guile version number in Presently there's no convention for having a Guile version number in
module C code filenames or directories. This is primarily because module C code filenames or directories. This is primarily because