[Top][All Lists]

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

Re: The load path

From: Neil Jerram
Subject: Re: The load path
Date: Fri, 12 Nov 2004 21:31:08 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

Andy Wingo wrote:

I disagree. When a user downloads an app, builds it and installs it,
they should be able to run it. On all configure scripts that I know
of, /usr/local is the default prefix. This is fine for C code: the
compiler will pick up headers, libs, and binaries from /usr/local, even
if the compiler comes from the distribution. Why should guile be any
different? Or to take your argument to its conclusion, why
include /usr/share/guile/site in the load path? After all, the distro
won't put anything there.
I agree: when Guile is built and installed using "configure; make; make install", the default load path should certainly include /usr/local. That's not quite what I was addressing though; I was talking about the case where everything on a machine is there through package management - in this case /usr/local isn't needed because there isn't anything in /usr/local.

My thinking was, that as soon as you have a user who is prepared to do "configure; ...", you have a user who can edit init.scm to add any load path that isn't already there. (E.g. the case where Guile is installed as a package, so is in /usr, but the user builds and installs an add-on .tar.gz themselves in /usr/local.)

Even for modules implementing functionality of an app, that aren't part
of its public interface?

Yes, absolutely!

My instinct is to hide them, because then I
know they won't cause me problems in the future if someone uses them
But surely "using them somehow" is what Free Software is all about?


reply via email to

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