Re: Another load path idea

[Greg Troxel]

Kevin Ryde <address@hidden> writes:

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

I concur with Neil, but his example does not fully cover the
possibilities.  It's true that on a Linux system guile will be in /usr
and some random hand-built package with no --prefix will end up in
/usr/local.  Yes, adding /usr/local will fix this, but also perhaps
pick up unintended stuff.

On NetBSD (and other pkgsrc systems), guile will be ok /usr/pkg, and
hand-built programs may be in /usr/local, or someplace else.  I tend
to build program foo (from CVS) into /usr/foo.  So IMHO a general
mechanism is required.

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

Exactly, and that's the issue.

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

Yes, but there are two sane cases:

  * put stuff in the same prefix as guile, following standards for
    $(prefix)/share/guile/site etc.

  * put stuff in some other prefix, still following standards,
    e.g. $(otherprefix)/share/guile/site

I have run into the second case a lot myself.

> I think it will be enough to,
> 
> 1. Add /usr/local into the default %load-path.

I'm not sure I like this.  NetBSD philosophy is not to include
/usr/local (include, lib) by default in system tools.  But it seems
reasonable.

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

Sure, this makes sense, but doesn't address what I see as the dominant
practical issue of someone installing something with a new prefix.
But certainly if a particular system has a notion of two or more
prefixes that should generally be searched, then packagers for that
system should make guile do that.  NetBSD pkgsrc does this routinely
(to look in /usr/pkgsrc, not two places).

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

/site?

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

Yes - in particular, I think a scm module should cons up an absolute
path for loading binaries based on it's own $prefix at configure
time.  I've done this with foo.scm.in and autoconf.


An important point is that some people (including me) believe that
only files managed by a pkg system belong in the prefix assigned to
the system.  I think it's been accepted that this view is reasonable
and that guile should accomodate those who run their systems this way
(as well as those who put things in the same prefix).

-- 
        Greg Troxel <address@hidden>