unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-user@gnu.org
Subject: Re: Modified load-path proposal
Date: Thu, 12 Jan 2006 18:01:33 +0000	[thread overview]
Message-ID: <87bqyhjpfm.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0601102326220.22427@ariel.telltronics.org> (steve tell's message of "Tue, 10 Jan 2006 23:49:59 -0500 (EST)")

steve tell <tell@telltronics.org> writes:

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

Thanks for both!

>> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>>
>>> 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.

OK.

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

Yes, if you already have one; I wouldn't spend too much time, though,
because there are reasons why a good system for one app is not good
for another.  (Emacs vs. Guile, for example.)

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

Yes, this is pretty much the direction we seem to be moving in now:
see my last post in the "Another load path idea" thread.

> Important details to address:
> - how to control the order in which things appear in %load-path

My inclination is that it is a bug if order is important, but I don't
have much experience to be sure about this yet.  Do you have real
examples where ordering is important?

> - how to make this play well with multiple versions of guile installed
> on the same system.

Can you say more about the problems you have in mind, and how you
think they can be addressed?

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

Thanks; it's the "Another load path idea" thread.

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

Yes, this is exactly the kind of case I have in mind as needing
fixing.  (And I have very similar cases with my packages.)

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


  reply	other threads:[~2006-01-12 18:01 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-13 18:21 Modified load-path proposal Neil Jerram
2005-10-13 18:40 ` Greg Troxel
2005-10-13 22:08   ` Neil Jerram
2005-10-14  0:37     ` Greg Troxel
2005-10-14  1:28       ` Andreas Rottmann
2005-10-15 11:17         ` Neil Jerram
2005-10-15 15:03           ` Greg Troxel
2005-10-15 17:53             ` Neil Jerram
2005-10-22 23:16           ` Kevin Ryde
2005-10-28 17:45             ` Neil Jerram
2005-10-30 18:04               ` Neil Jerram
2005-10-30 18:15                 ` Tomas Zerolo
2005-10-30 20:37                 ` Thien-Thi Nguyen
2005-10-30 22:59                   ` Neil Jerram
2005-10-31 10:55                     ` Thien-Thi Nguyen
2005-10-31 19:22                       ` Neil Jerram
2005-11-08 12:37                         ` Thien-Thi Nguyen
2005-10-31 13:17                   ` Tomas Zerolo
2005-10-30 23:48                 ` Kevin Ryde
2005-10-31 13:20                   ` Tomas Zerolo
2005-10-31 19:20                   ` Neil Jerram
2005-10-31 23:54                     ` Kevin Ryde
2005-11-12  9:47                       ` Neil Jerram
2005-11-01 23:31                     ` Vorfeed Canal
2005-11-12 17:54                       ` Neil Jerram
2005-11-02  8:44                 ` Ludovic Courtès
2005-12-03 13:05                   ` Neil Jerram
2005-12-13  8:38                     ` Ludovic Courtès
2005-12-16  0:16                       ` Neil Jerram
2005-12-16  1:00                         ` Neil Jerram
2005-12-16  9:55                         ` Ludovic Courtès
2006-01-07 13:37                           ` Neil Jerram
2006-01-11  4:49                             ` steve tell
2006-01-12 18:01                               ` Neil Jerram [this message]
2005-10-15 11:24       ` Neil Jerram
2005-10-15 15:01         ` Greg Troxel
2005-10-15 17:49           ` Neil Jerram
2005-10-14  7:24 ` Ludovic Courtès
2005-10-15 11:55   ` Neil Jerram
2005-10-15 15:40     ` Greg Troxel
2005-10-17  8:04       ` Ludovic Courtès
2005-10-17 17:52         ` Greg Troxel
2005-10-18  8:23           ` Search path for C libraries Ludovic Courtès
2005-10-18 10:12             ` Vorfeed Canal
2005-10-17 17:54         ` Modified load-path proposal Neil Jerram
2005-10-18  7:57           ` Ludovic Courtès
2005-10-19 22:30             ` Neil Jerram
2005-10-20  7:56               ` Vorfeed Canal
2005-10-20  8:05               ` Ludovic Courtès
2005-10-20 22:23                 ` Neil Jerram
2005-10-21  7:59                   ` Ludovic Courtès
2005-10-17 18:10       ` Neil Jerram
2005-10-18 16:16         ` Greg Troxel
2005-10-18 21:24           ` Vorfeed Canal
2005-10-19 22:29           ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bqyhjpfm.fsf@ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).