guile-user
[Top][All Lists]
Advanced

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

Re: Modified load-path proposal


From: steve tell
Subject: Re: Modified load-path proposal
Date: Tue, 10 Jan 2006 23:49:59 -0500 (EST)



Just a little note to say that I've been following along and am glad this is being discussed - and of course a few comments.

On Sat, 7 Jan 2006, Neil Jerram wrote:

address@hidden (Ludovic Court├Ęs) writes:

Neil Jerram <address@hidden> writes:

How so?  Given that you're about to do a (use-modules (whatnot)), I
can't see that also doing (initialize-packages "whatnot") will make a
significant difference.

Because people haven't been doing so for years.  Some of us certainly
don't want to iterate over each and every Guile module to add this line.

I agree that an addition to the module-using or module-declaring forms should be avoided.

This is based on the observation that (i) we want modules to be
installable in *any* directory, but (ii) at some point, there must be a
*fixed* directory to look for files to bootstrap further file loading.

This general guideline seems to be on the right track:
Lots of tools seem to have grown foo.conf.d directories, probably because they're friendly to package managers.

Would a survey of conventions for such configuration-directories and how they work be fruitful? One thing I notice is that systems where performance is important seem to "compile" the contents of the config directory into a single file which can be read rapidly.
Examples are /ld.so.conf.d incorporated into ld.so.cache by ldconfig,
and Debian's update-modules building /etc/modules.conf from /etc/modutils.

The guile analogy might be guile-config (a program run by package-post-install scripts) collecting %load-path fragments from $prefix/etc/guile-conf.d/* into $prefix/share/guile/config.scm
(where $prefix is the prefix that guile was built with).

guile-config could be little more than cat, or could do more complex validation of the contents of each file in the config directory. Likely it should remove duplicate %load-path entries, at least. But the scanning of the directory is done only when needed, when a package containing a guile module is added or removed.

Important details to address:
- how to control the order in which things appear in %load-path
- how to make this play well with multiple versions of guile installed on the same system.


It seems to me that neither of these ideas (yours and mine) quite fly
yet.  I have yet another idea, though, that I'll post in a separate
thread shortly.

I'll look for that and keep reading.  Thanks for thinking about this.

My interest in part comes from maintaining a package that uses guile and guile-gtk. It seems that most of my users' problems come when they try to install guile-gtk from source (into /usr/local) but have guile installed from their linux distribution (in /usr). My advice to date is generally to always install guile-gtk and guile in the same way: either both from source (say into /usr/local) or to build and install both using their package manager. Or else to become wizards at setting up the right environment variables.
But it would be nice if the more common case would just work.

Steve

reply via email to

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