unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Kevin Ryde <user42@zip.com.au>
Subject: Re: Another load path idea
Date: Fri, 27 Jan 2006 10:00:25 +1100	[thread overview]
Message-ID: <87irs68uie.fsf@zip.com.au> (raw)
In-Reply-To: <87fynaagju.fsf@ossau.uklinux.net> (Neil Jerram's message of "Thu, 26 Jan 2006 20:19:01 +0000")

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> The basic scenario is this: someone has Guile installed (probably by
> their distro) in /usr, and then builds and installs an additional
> package using ./configure && make && sudo make install, which installs
> with a different prefix than /usr (usually /usr/local).  Then they try
> to do a (use-modules (newly-installed-package)), and it doesn't work,
> because the installed Guile's load path doesn't include anything
> beginning with /usr/local/share/guile.

/usr/local should probably be in the defaults.  Of course there's
nothing to stop a distro packaged guile from doing that right now, if
/usr/local is the preferred location for non-distro stuff.

> No; the idea is that each installed package does whatever is needed to
> allow Guile (or any other Guile package) to bootstrap its modules.

I think that's the wrong way around, that it should be a job for the
sysadmin.

Basically, if someone installs in an unusual location then they're
doing something unusual; and consequently will need to tell some,
maybe all, of their installed guiles to look there.  Perhaps for all
users, perhaps just for themself, etc.

I reckon there's much more benefit in getting the guile recommended
locations better described, some sample automakery or whatever,
ie. better to define and assist normal setups, than to try to make
arbitrary arrangements work.  I doubt anybody will want completely
arbitrary anyway, surely there's only a handful of different cases.

I think it will be enough to,

1. Add /usr/local into the default %load-path.

2. Put a note in the manual inviting package builders to augment
   %load-path further if they wish, eg. for /opt.  (By patching
   boot-9.scm I would think.)

3. Put a note in the manual encouraging the use of /site by sysadmins,
   but with an invitation to extend %load-path if they've got good
   reason for violating the usual setup.

And a bit later (but actually needs doing either way),

4. Describe better in the manual how a .scm module should hit its own
   installed C code modules using load-extension.


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


  reply	other threads:[~2006-01-26 23:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-07 13:42 Another load path idea Neil Jerram
2006-01-12  9:38 ` Ludovic Courtès
2006-01-12 17:44   ` Neil Jerram
2006-01-19  9:21     ` Ludovic Courtès
2006-01-20 21:21       ` Kevin Ryde
2006-01-21  9:01       ` Neil Jerram
2006-01-22 15:38         ` Andy Wingo
2006-01-26  0:55           ` Kevin Ryde
2006-01-26  8:39             ` Ludovic Courtès
2006-01-26 20:19           ` Neil Jerram
2006-01-26 23:00             ` Kevin Ryde [this message]
2006-01-27  8:57               ` Ludovic Courtès
2006-01-28  0:39                 ` Kevin Ryde
2006-01-30  9:11                   ` Ludovic Courtès
2006-02-04 16:44                     ` Neil Jerram
2006-01-29 22:39               ` Greg Troxel
2006-01-31 20:23                 ` Kevin Ryde
2006-01-31 20:58                   ` Greg Troxel
2006-01-23  8:27         ` Ludovic Courtès
2006-01-23 20:04           ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87irs68uie.fsf@zip.com.au \
    --to=user42@zip.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).