steve tell <[EMAIL PROTECTED]> 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!
>> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>>> Because people haven't been doing so for years. Some of
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
[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 s
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 itera
Neil Jerram <[EMAIL PROTECTED]> writes:
> [... initialize-packages vs. config.scm approach ...]
I just thought of one more argument that favours initialize-packages,
namely that initialize-packages allows execution of arbitrary code to
initialize a package (whereas config.scm would only modify
%l
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> I think this rules out any kind of iteration through a .d directory
>> from init.scm. Apologies for not seeing this consideration before.
>
> Agreed. Guile already takes almost two seconds to start up on m
Hi Neil,
Sorry for the delay in answering your proposal.
Neil Jerram <[EMAIL PROTECTED]> writes:
> I think this rules out any kind of iteration through a .d directory
> from init.scm. Apologies for not seeing this consideration before.
Agreed. Guile already takes almost two seconds to start u
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Sorry to have been carrying on this discussion for so long, and for
>> changing direction a couple of times. If anyone is still reading, I'd
>> appreciate hearing your thoughts (again).
>
> Just a quick not
Vorfeed Canal <[EMAIL PROTECTED]> writes:
> Just FYI: Windows DOES have symlinks:
> http://www.sysinternals.com/Utilities/Junction.html
> as well as hardlinks:
> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_hardlink.mspx
Thanks. This still appears to be o
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>>
>> In practice I would guess not. Most distribution-managed packages
>> would go into /usr/share/guile, and most home-built packages into
>> /usr/local/share/guile, I'd guess. What is your concern, though?
>
> Ma
From: Neil Jerram <[EMAIL PROTECTED]>
Date: Mon, 31 Oct 2005 19:22:31 +
> both interpretations are fine.
Yes, but which one did you mean? It seems to me that they have
opposite implications.
i didn't have any one specific idea in mind. that there are conflicting
implications
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Sorry to have been carrying on this discussion for so long, and for
> changing direction a couple of times. If anyone is still reading, I'd
> appreciate hearing your thoughts (again).
Just a quick note to say:
0. I'm still reading. ;-)
1. Your `i
On 10/31/05, Neil Jerram <[EMAIL PROTECTED]> wrote:
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>
> > What advantage is this over putting a symlink in /usr/share/guile/site
> > to point to this alternate location?
>
> Nothing really compelling, perhaps, but...
>
> - some OSs don't have symlinks (i.e.
On Sun, Oct 30, 2005 at 06:04:58PM +, Neil Jerram wrote:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
> > So all that's left is:
[...]
> > Everyone happy with that?
>
> Well, I'm not sure I am. [...]
[init.d]
> Sorry to have been carrying on this discussion for so long, and for
> changing d
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> In practice I would guess not. Most distribution-managed packages
> would go into /usr/share/guile, and most home-built packages into
> /usr/local/share/guile, I'd guess. What is your concern, though?
Mainly that I think you can get what you want from
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
>From: Neil Jerram <[EMAIL PROTECTED]>
>Date: Sun, 30 Oct 2005 22:59:32 +
>
>Not sure what you mean by "to get around it". Do you mean that
>someone will change the design so that the interface does the
>enforcement itself; or t
Kevin Ryde <[EMAIL PROTECTED]> writes:
> What advantage is this over putting a symlink in /usr/share/guile/site
> to point to this alternate location?
Nothing really compelling, perhaps, but...
- some OSs don't have symlinks (i.e. Windows)
- the symlink approach doesn't work if a package instal
On Mon, Oct 31, 2005 at 10:48:43AM +1100, Kevin Ryde wrote:
> Neil Jerram <[EMAIL PROTECTED]> writes:
> >
> > In the init.d approach [...]
> What advantage is this over putting a symlink in /usr/share/guile/site
> to point to this alternate location?
Something similar to what the /etc/init.d thin
On Sun, Oct 30, 2005 at 03:37:33PM -0500, Thien-Thi Nguyen wrote:
>From: Neil Jerram <[EMAIL PROTECTED]>
>Date: Sun, 30 Oct 2005 18:04:58 +
>
>We could enforce this by [...]
>I'd appreciate hearing your thoughts (again).
>
> if your design requires enforcement, [...]
Neil con
From: Neil Jerram <[EMAIL PROTECTED]>
Date: Sun, 30 Oct 2005 22:59:32 +
Not sure what you mean by "to get around it". Do you mean that
someone will change the design so that the interface does the
enforcement itself; or that if the interface is precise about what it
allows,
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> In the init.d approach, there would be a directory named
> $sysconfdir/guile/X.Y/init.d, and we would distribute an init.scm file
> (which Guile normally loads on startup) which would load all the files
> in $sysconfdir/guile/X.Y/init.d. So, for example,
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
>From: Neil Jerram <[EMAIL PROTECTED]>
>Date: Sun, 30 Oct 2005 18:04:58 +
>
>We could enforce this by [...]
>I'd appreciate hearing your thoughts (again).
>
> if your design requires enforcement, someone will want to
> redesign it la
From: Neil Jerram <[EMAIL PROTECTED]>
Date: Sun, 30 Oct 2005 18:04:58 +
We could enforce this by [...]
I'd appreciate hearing your thoughts (again).
if your design requires enforcement, someone will want to
redesign it later to get around it. you might as well
put yourself in the
Andy Wingo <[EMAIL PROTECTED]> writes:
> Hi all,
>
> What is the load path proposal?
>
> Sorry to be obtuse but the thread is really long and I'd like an idea of
> where the proposal stands, now that it's almost ready.
Andy,
Please see the email I just sent to
Neil Jerram <[EMAIL PROTECTED]> writes:
> So all that's left is:
>
> - config.scm, as previously described but with simpler format like
> this:
>
> ((load-path
> "/usr/share/guile/site"
> "/usr/share/guile"
> "/usr/share/guile/1.6"
> ...)
>...)
>
> - Guile's reading of conf
Hi all,
What is the load path proposal?
Sorry to be obtuse but the thread is really long and I'd like an idea of
where the proposal stands, now that it's almost ready.
Regards,
--
Andy Wingo
http://wingolog.org/
___
Guile-user mailing
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I think there's some confusion here.
>
> The automake docs read like AM_PATH_LISPDIR goes to wherever emacs is
> installed, but looking at the code for that macro, and giving it a
> run, I believe it merely chooses between
>
> $libdir/emacs/site-lisp
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> Also note that for Elisp files the recommended method is to use
> AM_PATH_LISPDIR, which will install Elisp files to wherever your Emacs
> is installed, not to $prefix.
I think there's some confusion here.
The automake docs read like AM_PATH_LISPDIR goe
Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>> What I'm saying in (1) is that the user should be able to choose these
>> two (or three) directories at installation time.
>
> Perhaps, yes, but I don't (personally) want to get into the object/lib
> file loc
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Sorry, I'm not understanding how guilelibdir/guileobjectdir differ
>> from (2).
>
> You proposed a single M4 macro, `GUILE_SCHEME_DIR', which would provide
> the user with the ability to customize only *one*
Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> There were really two points in my message:
>>
>> 1. Autoconf/Automake (and, consequently, the user) _must_ know about
>> these three different directories, namely `guileschemedir',
>> `guilelibdir'
On 10/20/05, Neil Jerram <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> > 2. While we're at it, we might want to use your mechanism as well for
> > shared objects.
>
> Sorry, I'm not understanding how guilelibdir/guileobjectdir differ
> from (2).
I think it does
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> There were really two points in my message:
>
> 1. Autoconf/Automake (and, consequently, the user) _must_ know about
> these three different directories, namely `guileschemedir',
> `guilelibdir' and `guileobjectdir', instead of only one direct
Greg Troxel <[EMAIL PROTECTED]> writes:
> That all sounds fine, except that I think (policy!) we should either
> discourage putting stuff under 1.6, or suggest 1.6/site, so that
> guile's own files and other stuff are cleanly separated. I agree that
> mechanism sufficient for various policies is
On 18 Oct 2005 12:16:05 -0400, Greg Troxel <[EMAIL PROTECTED]> wrote:
> That all sounds fine, except that I think (policy!) we should either
> discourage putting stuff under 1.6, or suggest 1.6/site, so that
> guile's own files and other stuff are cleanly separated. I agree that
> mechanism suffic
That all sounds fine, except that I think (policy!) we should either
discourage putting stuff under 1.6, or suggest 1.6/site, so that
guile's own files and other stuff are cleanly separated. I agree that
mechanism sufficient for various policies is the key point, but think
we also need to suggest
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> In principle yes, the current mechanism we're discussing for load-path
> could be extended to `guilelibdir' and `guileobjectdir'. But
> personally I don't want to go anywhere near there just yet - it's hard
> enough trying to tie down all the details
Greg Troxel <[EMAIL PROTECTED]> writes:
> before deciding about tags and descriptions, I think we need to be
> clearer on the semantics of these directories and why they'd be
> used. [...]
Greg, I'm sorry but I don't want to comment in detail on everything
you've said. In my view what you have d
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> In fact, maybe we should just mimic Autoconf/Automake and the GNU
> Standards[0] by (i) identifying exactly what the various installation
> directories we care about are, (ii) ensuring that they can be configured
> at installation-time, and (iii) make
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> I don't think we should reason about installation directories in terms
> of packaging-system-managed vs. human-managed installations. I think
> the packaging system is just a special case of the "human-managed
> installation". However, packaging syst
Hi,
Greg Troxel <[EMAIL PROTECTED]> writes:
> before deciding about tags and descriptions, I think we need to be
> clearer on the semantics of these directories and why they'd be used.
> Let me take a stab at it, and I'm sure I'll leave out other's use
> cases.
I don't think we should reason abo
Greg Troxel <[EMAIL PROTECTED]> writes:
> The mechanism I'm proposing is a bit more flexible than that, but the
> basic idea in both cases is that the core distribution (either Emacs
> or Guile) has a view on where it wants add-on packages to be installed
> (and hence which may be differen
Greg Troxel <[EMAIL PROTECTED]> writes:
> I meant that when a guile-using package does 'make install', it can
> hook itself into the already-installed guile. Guile can and certainly
> should create config.scm in the build tree before install. Then,
> regardless of whether a binary package of som
before deciding about tags and descriptions, I think we need to be
clearer on the semantics of these directories and why they'd be used.
Let me take a stab at it, and I'm sure I'll leave out other's use
cases.
$(guileprefix)/share/guile
top-level place within guile's prefix. currently has sl
The mechanism I'm proposing is a bit more flexible than that, but the
basic idea in both cases is that the core distribution (either Emacs
or Guile) has a view on where it wants add-on packages to be installed
(and hence which may be different from the add-on package's $prefix).
I think th
Neil Jerram <[EMAIL PROTECTED]> writes:
> Greg Troxel <[EMAIL PROTECTED]> writes:
>
> > I was trying to contort the tag mechanism into doing what you showed
> > how to do earlier. Now I realize there's no need, so with the caveat
> > that I'd like the docs to explain how to do in-own-prefix inst
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil, I also fully support your proposal.
Thanks.
>> ((load-path
>> local
> ^
>
> I'd make this `local-1.6' by default, assuming that modules that may
> flawlessly run on any Guile version are an exception rather than the
> rule
Yes, agree
Greg Troxel <[EMAIL PROTECTED]> writes:
> I was trying to contort the tag mechanism into doing what you showed
> how to do earlier. Now I realize there's no need, so with the caveat
> that I'd like the docs to explain how to do in-own-prefix installs as
> you did in email, I can fully support you
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> I strongly support making this the default/standard way, too. I'd be
> highly annoyed (well, that's an understatement ;)) if a "./configure
> && make && sudo make install" of some package would put files under
> /usr just because guile happens to be i
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> I think this meets everyone's desires ... please let me know what you
> think!
Neil, I also fully support your proposal.
> ((load-path
> local
^
I'd make this `local-1.6' by default, assuming that modules that may
flawlessly run on any Gu
Greg Troxel <[EMAIL PROTECTED]> writes:
> Yes it does (I think). If that's what you want, you just write your
> Makefile.am like this ...
>
> scmdatadir = $(datadir)/guile
> scmdata_DATA = whatever1.scm whatever2.scm
>
> ... and add an extra install step (for which I forget the syntax)
Yes it does (I think). If that's what you want, you just write your
Makefile.am like this ...
scmdatadir = $(datadir)/guile
scmdata_DATA = whatever1.scm whatever2.scm
... and add an extra install step (for which I forget the syntax)
that does
guile-config add-load-path mydata
Greg Troxel <[EMAIL PROTECTED]> writes:
> We need remove-load-path too, for cleanup.
OK.
(Actually, "add" should probably be "ensure", and only add the
directory if not already in config; and "remove" should probably be
"cleanup", and only do anything if there is nothing left under the
relevant
We need remove-load-path too, for cleanup.
It's not clear to me how the default version of config shows up in a
fresh guile build/install. I'd argue that only the traditional three
dirs in prefix should be there by default. Perhaps configure can have
a "--add-load-path /usr/local/share/guile" to
I think this meets everyone's desires ... please let me know what you
think!
Neil
-*- scheme -*-
;; 1. Format and example contents of
;; $sysconfdir/guile/$EFFECTIVE_VERSION/config.scm
;;
;; The format is a single alist expression which Guile reads.
;; (config.scm i
55 matches
Mail list logo
