unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* doc libdir and C code modules
@ 2006-02-04  0:28 Kevin Ryde
  2006-02-04 15:38 ` Neil Jerram
  2006-02-06  9:31 ` Ludovic Courtès
  0 siblings, 2 replies; 8+ messages in thread
From: Kevin Ryde @ 2006-02-04  0:28 UTC (permalink / raw)


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-04  0:28 doc libdir and C code modules Kevin Ryde
@ 2006-02-04 15:38 ` Neil Jerram
  2006-02-05 23:21   ` Kevin Ryde
  2006-02-07  0:03   ` Kevin Ryde
  2006-02-06  9:31 ` Ludovic Courtès
  1 sibling, 2 replies; 8+ messages in thread
From: Neil Jerram @ 2006-02-04 15:38 UTC (permalink / raw)


Kevin Ryde <user42@zip.com.au> writes:

> 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.

Very nice, thanks.  Amongst other things, I didn't realize that
Autoconf could do @libdir@ substitutions so conveniently.

   Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-04 15:38 ` Neil Jerram
@ 2006-02-05 23:21   ` Kevin Ryde
  2006-02-07  0:03   ` Kevin Ryde
  1 sibling, 0 replies; 8+ messages in thread
From: Kevin Ryde @ 2006-02-05 23:21 UTC (permalink / raw)
  Cc: guile-devel

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> I didn't realize that
> Autoconf could do @libdir@ substitutions so conveniently.

I've got a suspicion the gnu standards call for them to be done at
make-time rather than configure-time.  I forget where it says or said
that, the distinction is too subtle to want to talk about though.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-04  0:28 doc libdir and C code modules Kevin Ryde
  2006-02-04 15:38 ` Neil Jerram
@ 2006-02-06  9:31 ` Ludovic Courtès
  2006-02-07  0:11   ` Kevin Ryde
  1 sibling, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2006-02-06  9:31 UTC (permalink / raw)


Kevin Ryde <user42@zip.com.au> writes:

> 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.

Cool!

>    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'.

Shouldn't there be a note saying that the actual shared library name
will follow the system's naming convention, be it `libfoobar-c-code.so',
`libfoobar-c-code.sl', `foobar-c-code.dll', etc.?  Perhaps with a link
to `(libtool.info.gz)Libltdl interface' mentioning `lt_dlopenext ()'?

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-04 15:38 ` Neil Jerram
  2006-02-05 23:21   ` Kevin Ryde
@ 2006-02-07  0:03   ` Kevin Ryde
  2006-02-09  9:49     ` Neil Jerram
  1 sibling, 1 reply; 8+ messages in thread
From: Kevin Ryde @ 2006-02-07  0:03 UTC (permalink / raw)
  Cc: guile-devel

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> I didn't realize that Autoconf could do @libdir@ substitutions so
> conveniently.

Actually I had it a bit wrong, the usual autoconf $(libdir) value
needs to get expanded by some shell/make.  That'd be why I've been
using that way I guess :-).  I updated the manual.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-06  9:31 ` Ludovic Courtès
@ 2006-02-07  0:11   ` Kevin Ryde
  0 siblings, 0 replies; 8+ messages in thread
From: Kevin Ryde @ 2006-02-07  0:11 UTC (permalink / raw)


ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> Shouldn't there be a note saying that the actual shared library name
> will follow the system's naming convention, be it `libfoobar-c-code.so',
> `libfoobar-c-code.sl', `foobar-c-code.dll', etc.?

I put "(etc)", don't want to clutter with an essay on non-gnu systems.

> Perhaps with a link to `(libtool.info.gz)Libltdl interface'
> mentioning `lt_dlopenext ()'?

Hmm.  Leave that to the load-extension doc maybe.  You don't have to
use libtool to use C code modules.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-07  0:03   ` Kevin Ryde
@ 2006-02-09  9:49     ` Neil Jerram
  2006-02-14 19:47       ` Greg Troxel
  0 siblings, 1 reply; 8+ messages in thread
From: Neil Jerram @ 2006-02-09  9:49 UTC (permalink / raw)


Kevin Ryde <user42@zip.com.au> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>> I didn't realize that Autoconf could do @libdir@ substitutions so
>> conveniently.
>
> Actually I had it a bit wrong, the usual autoconf $(libdir) value
> needs to get expanded by some shell/make.  That'd be why I've been
> using that way I guess :-).  I updated the manual.

Yes, that sounds more like what I thought you had to do.  It's a shame
that this isn't as easy as just putting @libdir@ in a .in file.

     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: doc libdir and C code modules
  2006-02-09  9:49     ` Neil Jerram
@ 2006-02-14 19:47       ` Greg Troxel
  0 siblings, 0 replies; 8+ messages in thread
From: Greg Troxel @ 2006-02-14 19:47 UTC (permalink / raw)
  Cc: guile-devel

Neil Jerram <neil@ossau.uklinux.net> writes:

> Kevin Ryde <user42@zip.com.au> writes:
> 
> > Neil Jerram <neil@ossau.uklinux.net> writes:
> >
> > Actually I had it a bit wrong, the usual autoconf $(libdir) value
> > needs to get expanded by some shell/make.  That'd be why I've been
> > using that way I guess :-).  I updated the manual.
> 
> Yes, that sounds more like what I thought you had to do.  It's a shame
> that this isn't as easy as just putting @libdir@ in a .in file.

That's bogus of autoconf, but hard to fix.  I use @prefix@/lib, which
isn't right, but works ~almost always and is easy.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-02-14 19:47 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-04  0:28 doc libdir and C code modules Kevin Ryde
2006-02-04 15:38 ` Neil Jerram
2006-02-05 23:21   ` Kevin Ryde
2006-02-07  0:03   ` Kevin Ryde
2006-02-09  9:49     ` Neil Jerram
2006-02-14 19:47       ` Greg Troxel
2006-02-06  9:31 ` Ludovic Courtès
2006-02-07  0:11   ` Kevin Ryde

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).