guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another load path idea


From: Kevin Ryde
Subject: Re: Another load path idea
Date: Fri, 27 Jan 2006 10:00:25 +1100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Neil Jerram <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]