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:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Neil Jerram <[EMAIL PROTECTED]> 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
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
