This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: initial %load-path


i'm moving this discussion over to the main guile mailing list since
bug-guile is not read by as many people...

Marius Vollmer writes:

 > thi <ttn@mingle.glug.org> writes:
 > 
 > > a (binary) guile module is not an ordinary library, however.
 > 
 > I think it is.  You can link to it and call its exported functions.
 > 
 > [dual nature of libguilegtk: useful to guile, useful to other modules]
 > [issues w/ run-time dynamic linkers, specifically "double"-linking]
 > 
 > That's why I think it is safest to just admit that binary Guile
 > modules are ordinary libraries and live in the namespace of all the
 > other libraries.  I think we should assume that all platforms provide
 > dynamic linking and design the systems for that and then let libtool
 > and libltdl sort out all the problems of providing shared libraries.
 > Some platforms wont provide shared libraries, but this should be only
 > a loss in convenience (i.e. people will have to do large amounts of
 > recompilations) but no loss in functionality.

i guess it all depends on what conventions one includes in (or excludes
from) the concept of "ordinary".  random module M cannot use a "guile
module" unless it follows some usage conventions:

(1) call the `scm_init_<module>_module()' function on load;

(2) link against libguile (or be able to handle `SCM' as args and return
    value, otherwise);

(3) [optional] look for the "guile module" using
    `find-and-link-dynamic-module' from (ice-9 boot-9).

the impetus for the patch comes from (3), mostly.  in other words,
whether one calls the actual file ordinary or not isn't the point, the
point is (see subject) to better specify where that file lives (and
to provide the root of that tree in the load path) so that it can be
found w/ less futzing than currently.  sorry i didn't explain myself
better.

 > However, I agree that a flat namespace is bad.  I do not propose to
 > put binary Guile modules into a flat namespace.  Rather, I think that
 > such modules should be foremost treated as libraries.  Unfortunately,
 > Unix has a flat namespace for libraries but I think we can reasonable
 > cope with that by having a standard way to name our libraries,
 > starting with "libguile-", which nobody else should be using, and
 > separating the components of the hierarchical module name with "-"
 > instaed of "/".  Should be the same thing.  It wont be pretty with ls,
 > but hey, Unix has lost its elegance long ago.

one can always emulate flatness by symlinking into a tree.  in this way,
both hiearchial search (`find-and-link-dynamic-module') and flat search
(ld.so) are satisfied.

 > Assuming that we put all binary modules into the library namespace,
 > how can we find them automatically?  How can we transparently replace
 > a Scheme file with a Hobbit-compiled version, like you can
 > transparently replace a Elisp file with a byte-compiled version?

from the search perspective, transparency is hindered by machine (arch)
dependency.  elisp .elc files have no restriction, so they can live
right next to their source.  for guile binary modules, however, things
are diffrent.  here is the scenario i picture:

- before compiling:
  - PRE/share/guile/MY/COOL/module.scm (has definitions)

- after compiling:
  - [optional] PRE/share/guile/MY/COOL/module.scm (has definitions)
  - PRE/lib/guile/MY/COOL/libmodule.{la,so}
  - PRE/lib/libMY-COOL-module.{la,so} -> guile/MY/COOL/libmodule.{la,so}
  
i used PRE for "PREFIX" to shorten the lines.  the "->" is a symlink.
the binary files should NOT be under PRE/share, which is reserved for
architecture-independent files.

in both cases, the load path would include PRE/lib/guile *in front of*
PRE/share/guile.  this is to handle the common case where source will
still be around after compiling.  before compiling, inclusion of
PRE/lib/guile will result in some (hopefully small) overhead.

thus, the gist of the proposed change is to add PRE/lib/guile to the
initial load path, in front of PRE/share/guile.

 > I think this should be split between the module system and `load'.  (I
 > thought differently about this issue when I implemented the current
 > hack in boot-9, and I remeber that there was some discussion where I
 > didn't want to see the point, but I think I now do).
 > 
 > When `load' is called with a filename that has no extension, it tries
 > a small number of extensions and chooses the first file it finds (or
 > the youngest one?).  All extensions would indicate ordinary Guile
 > Scheme code (just like an ".elc" file can be read as ordinary Elisp).
 > The extension ".scm" would be used for hand-written Scheme code,
 > ".scm-b" could be used for a bytecode version of the ".scm" file, and
 > ".scm-c" could be used for a Hobbit compiled version.  A ".scm-c" file
 > would not be the shared library itself.  Rather, it would only contain
 > something like
 > 
 >     (load-dynamic-library "libguile-sim-math" "scm_sim_math_init")
 > 
 > The function `load-dynamic-library' could be simply defined as
 > 
 >     (define (load-dynamic-library lib init)
 >       (dynamic-call init (dynamic-link lib)))
 > 
 > that is, all library searching magic would be left to `dynamic-link'
 > which would simply call libltdl.
 > 
 > The searching of module implementation files would be done by the
 > module system, just as it is done now.  It would probably look for a
 > ".scm" file and strip the extension before calling `load'.  The idea
 > is that a ".scm-c" file is only valid when there is a corresponding
 > ".scm" file.  When one wants to have a module that has only a shared
 > library implementation and no Scheme source code, one should put the
 > `load-dynamic-library' call into a ".scm" file.
 > 
 > The above assumes that the shared library initialization code also
 > contains the effects of `define-module' (if appropriate).  Much of the
 > baroqueness of the current binary modules implementation in boot-9
 > stem from the fact that such effects were not easily obtainable from C
 > code at the time (or at least, it appeared to me to be the case).  I
 > think we now should really provide a scm_define_module call, if there
 > isn't one already.

the approach you describe here sounds reasonable; if you add symlinking
from flat space to tree space instead of requiring complete flattening,
i think we'd almost be saying the same thing.  :->

 > > [...] look at it this way: the other approach to consistency would
 > > require us to rename text files as ice-9-boot-9.scm,
 > > ice-9-format.scm and so on.
 > 
 > Hmm, yes, using "-" might not be the best idea.  What about "|"?
 > Would something like "libguile|sim|math.la" cause problems?

another approach is to wrap the hierarchical search in a simple
libaccessguilemodules that calls `find-and-link-dynamic-module' (or
whatever).  this could live in PRE/lib and do the flat space to tree
space conversion dynamically.  could possibly help in situations where
symlinks are not available (windows?).

thi

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]