[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>>
>>> (i) a config file holding the default value of `%load-path',
>>
>> If you really want to add something, just load an /etc/guilerc at
>> startup.
>
>
I like that too except usually a subdir of wherever I keep the source.
Nice and easy to rm -r when you're sick of it. But I presume you, as
I, don't want a package build trying to modify /etc/profile etc to
hook itself into $PATH. I might well add it in myself, even setup to
test a rang
Greg Troxel <[EMAIL PROTECTED]> writes:
>
> I tend to build program foo (from CVS) into /usr/foo.
I like that too except usually a subdir of wherever I keep the source.
Nice and easy to rm -r when you're sick of it. But I presume you, as
I, don't want a package build trying to modify /etc/profile
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> (i) a config file holding the default value of `%load-path',
>
> If you really want to add something, just load an /etc/guilerc at
> startup.
Sorry, I don't really understand how what you says differs
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> 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 inst
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> (i) a config file holding the default value of `%load-path',
If you really want to add something, just load an /etc/guilerc at
startup. That'd be all the flexibility and wouldn't force add-on
modules to jump through hoops (not until the hoops are mu
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I think it will be enough to,
>
> 1. Add /usr/local into the default %load-path.
>
> 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.)
>
>
Neil Jerram <[EMAIL PROTECTED]> 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
Andy Wingo <[EMAIL PROTECTED]> writes:
> Hi Neil,
>
> On Sat, 2006-01-21 at 09:01 +, Neil Jerram wrote:
>> Basically agreed, but what I now plan precisely is as follows.
>
> Oh good, a summary of this thread of many moons :)
I'm sorry it's gone on for so long. Every time we appear to near a
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Andy Wingo <[EMAIL PROTECTED]> writes:
>>
>> A question though. What is the problem which is being solved here?
>
> That's escaped me too.
>
> (I have a feeling the present "site" dir is modelled on emacs, I
> haven't been able to follow why it's not e
Andy Wingo <[EMAIL PROTECTED]> writes:
>
> A question though. What is the problem which is being solved here?
That's escaped me too.
(I have a feeling the present "site" dir is modelled on emacs, I
haven't been able to follow why it's not enough ...)
Hi Neil,
On Sat, 2006-01-21 at 09:01 +, Neil Jerram wrote:
> Basically agreed, but what I now plan precisely is as follows.
Oh good, a summary of this thread of many moons :)
A question though. What is the problem which is being solved here?
In guile-gnome I only really use the load path in
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> 1. /etc/guile/${GUILE_EFFECTIVE_VERSION}/load-path.scm
>>
>> Contains the calculated load path, e.g.
>>
>> ("/usr/share/guile/1.6"
>> "/usr/share/guile/site"
>> "/usr/share/guile"
>> "/opt/gnome/s
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> 1. /etc/guile/${GUILE_EFFECTIVE_VERSION}/load-path.scm
>
> Contains the calculated load path, e.g.
>
> ("/usr/share/guile/1.6"
> "/usr/share/guile/site"
> "/usr/share/guile"
> "/opt/gnome/share/guile")
>
> 2. Each Guile package installs a file und
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Well, in the big picture of Guile package development, both of these
>> concepts could be useful. If I'm understanding you correctly, I would
>> make the analogies that
>>
>> - a .la file is a bit l
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Libtool's `.la' files are only used at compile-time, in order to
> find out library dependencies,
They're also read at runtime for dlopens (see ltdl.c try_dlopen) to
get depencency info (for the benefit of non-ELF systems I think).
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Well, in the big picture of Guile package development, both of these
> concepts could be useful. If I'm understanding you correctly, I would
> make the analogies that
>
> - a .la file is a bit like a formal list of all a package's
> dependencies (w
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> The basic idea behind all of the previous proposals was to create some
> kind of config when a package was installed, such that other Guile
> code would be able to find that package automatically. But what if we
> do things the other way round? When
There has not been a resounding consensus for any of the proposals
discussed so far, so here is another possibility.
The basic idea behind all of the previous proposals was to create some
kind of config when a package was installed, such that other Guile
code would be able to find that package aut
19 matches
Mail list logo
