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
next prev parent 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).