unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Modified load-path proposal
@ 2005-10-13 18:21 Neil Jerram
  2005-10-13 18:40 ` Greg Troxel
  2005-10-14  7:24 ` Ludovic Courtès
  0 siblings, 2 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-13 18:21 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

I think this meets everyone's desires ... please let me know what you
think!

        Neil


[-- Attachment #2: load-path.txt --]
[-- Type: text/plain, Size: 5413 bytes --]

                      -*- 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 is not a file which Guile loads, and which could
;; therefore contain arbitrary code, because (i) it is used before
;; boot-9.scm is loaded, which means that bits of Scheme are not
;; available yet, and (ii) the specification of a standard format
;; allows us to use automated tools for updating the contents of the
;; file.)
;;
;; Each element of the alist is (INFO-TYPE . INFO), where the only
;; currently supported INFO-TYPE is load-path.  The alist format
;; allows us to extend the use of the config.scm in future, but in a
;; way that should not require existing code and tools (if well
;; written) to be updated.
;;
;; When INFO-TYPE is load-path, the form of INFO is (DEFAULT-TAG (TAG
;; DIRECTORY DESCRIPTION) ...), where:
;;
;; - DEFAULT-TAG is the tag of the default install location for Guile
;; packages.  In other words, it identifies the location that
;; GUILE_SCHEME_DIR will return if a package's ./configure is run
;; without a --with-guile-scheme-dir option.
;;
;; - TAG is an arbitrary symbol which can be used to uniquely identify
;; each load path directory.
;;
;; - DIRECTORY is a load path directory (as a string).
;;
;; - DESCRIPTION is a string describing the use of that load path
;; directory.

((load-path
  local
  (guile-1.6
   "/usr/share/guile/1.6"
   "Install location for Guile 1.6's own Scheme files")
  (site
   "/usr/share/guile/site"
   "Install location for site-specific Scheme files")
  (gnome
   "/opt/gnome/guile"
   "Install location for GNOME-related Scheme files")
  (local
   "/usr/local/share/guile"
   "Version-independent non-distribution-managed Scheme files")
  (local-1.6
   "/usr/local/share/guile/1.6"
   "1.6-dependent non-distribution-managed Scheme files")))


;; 2. Guile's startup logic
;;
;; Normal location of config.scm is hardcoded into Guile, based on the
;; setting of $sysconfdir at ./configure time.
;;
;; This location can be overridden at runtime by a --config=FILE
;; option (which we need to add).  This will be needed by
;; pre-inst-guile (during a Guile build), for example.
;;
;; Guile will abort if config.scm is not found, or cannot be read, or
;; there are any errors in the format of the information in it.
;;
;; Otherwise, Guile sets %load-path to:
;;
;;     (map cadr (cddr (assq 'load-path config)))
;;
;; (but in C code, not in Scheme).
;;
;; Thereafter %load-path is used as presently for the loading of
;; boot-9.scm, init.scm and so on.


;; 3. Code for guile-config add-load-path TAG DIRECTORY DESCRIPTION
;;
;; (To be integrated into guile-config, and will in practice need
;; error handling.)

(define (add-load-path tag directory description)
  (let* ((config (with-input-from-file %sys-config-file read))
         (load-path-info (assq 'load-path config)))
    (set-cdr! load-path-info
              (append! (cdr load-path-info)
                       (list (list tag
                                   directory
                                   description))))
    (with-output-to-file %sys-config-file
      (lambda ()
        (pretty-print config)))))


;; 4. Code for guile-config get-load-path ARG
;;
;; Where ARG is the string that was given to --with-guile-scheme-dir,
;; or an empty string if --with-guile-scheme-dir was not used.
;;
;; (To be integrated into guile-config, and will in practice need
;; error handling.)

(define (get-load-path arg)
  ;; If ARG begins with "/", use it directly.
  (if (and (>= (string-length arg) 1)
           (char=? (string-ref arg 0) #\/))
      arg
      ;; Otherwise we need to read config.
      (let* ((config (with-input-from-file %sys-config-file read))
             (load-path-info (assq 'load-path config))
             (tag (if (zero? (string-length arg))
                      ;; Use the default tag.
                      (cadr load-path-info)
                      ;; ARG should be a tag.
                      (string->symbol arg))))
        ;; Return the directory for the chosen tag.
        (cadr (assq tag (cddr load-path-info))))))


;; 5. Code for GUILE_SCHEME_DIR autoconf macro
;;
;; To be written, with these features/requirements:
;;
;; - Will check for a --with-guile-scheme-dir=ARG option.
;;
;; - Will use `guile-config get-load-path ARG` to get the appropriate
;; install directory.
;;
;; - Will NOT take a default-tag argument (in configure.in) as I
;; suggested before, because there is no way for the package author to
;; know what tags will be available on the distribution(s) where the
;; package is built.
;;
;; - Should fall back to other sensible mechanisms if `guile-config
;; get-load-path ARG` is not available.
;;
;;   + Recent Guile distributions have the GUILE_SITE_DIR macro.  In
;;   my view this is better than nothing, but it feels wrong for Guile
;;   package code to go under .../site.  So my preference if using
;;   GUILE_SITE_DIR would be to install to ${GUILE_SITE_DIR}/..
;;
;;   + One could run Guile to discover its %load-path, and decide
;;   heuristically which of those directories to install under.
;;
;;   + Note that there's no point in falling back to
;;   $prefix/share/guile, because if the package author wanted that
;;   they could have specified that directly instead of using
;;   GUILE_SCHEME_DIR.

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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  7:24 ` Ludovic Courtès
  1 sibling, 1 reply; 55+ messages in thread
From: Greg Troxel @ 2005-10-13 18:40 UTC (permalink / raw)
  Cc: Guile Users

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 make the install search
this, and this can be invoked by packaging systems that want it.  By

  ;; 5. Code for GUILE_SCHEME_DIR autoconf macro

This doesn't support the notion of putting things in
$(prefix)/share/guile, and adding that to the load path of the
existing guile when you do install.  Perhaps setting that up should be
a standard pre-step before building the new package, but I believe
that a package configured with --prefix=/usr/foo should only write to
/usr/foo.  I realize others disagree, but I'd like the mechanisms to
support this behavior.  perhaps the tag for /usr/foo/share/guile
should be /usr/foo, so packages can search for a load dir by their
prefix.  Perhaps there should be an optional argument that returns the
path now and causes creation of it at make install time.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-13 18:40 ` Greg Troxel
@ 2005-10-13 22:08   ` Neil Jerram
  2005-10-14  0:37     ` Greg Troxel
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-13 22:08 UTC (permalink / raw)
  Cc: Guile Users

Greg Troxel <gdt@ir.bbn.com> 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 directory; but those are next-level details.)

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

Yes, agreed.  (The default config.scm could be provided in the distro,
or could be generated during the make.)

>  Perhaps configure can have
> a "--add-load-path /usr/local/share/guile" to make the install search
> this, and this can be invoked by packaging systems that want it.  By

I don't think we need this, because it's equivalent to just running
guile-config add-load-path once after the install.

>   ;; 5. Code for GUILE_SCHEME_DIR autoconf macro
>
> This doesn't support the notion of putting things in
> $(prefix)/share/guile, and adding that to the load path of the
> existing guile when you do install.

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 $(datadir)/guile "My Location"

Am I still missing something?

>  Perhaps setting that up should be
> a standard pre-step before building the new package, but I believe
> that a package configured with --prefix=/usr/foo should only write to
> /usr/foo.  I realize others disagree, but I'd like the mechanisms to
> support this behavior.  perhaps the tag for /usr/foo/share/guile
> should be /usr/foo, so packages can search for a load dir by their
> prefix.  Perhaps there should be an optional argument that returns the
> path now and causes creation of it at make install time.

I don't see your point - can you be more concrete?

Thanks,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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:24       ` Neil Jerram
  0 siblings, 2 replies; 55+ messages in thread
From: Greg Troxel @ 2005-10-14  0:37 UTC (permalink / raw)
  Cc: Guile Users

  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 $(datadir)/guile "My Location"

  Am I still missing something?

No, you're not - that's just fine, and would be IMHO the 'standard
way' to do things, or at least one of two ways, with the other
probably being putting stuff in $(guile-prefix)/share/guile.

  I don't see your point - can you be more concrete?

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

-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-14  0:37     ` Greg Troxel
@ 2005-10-14  1:28       ` Andreas Rottmann
  2005-10-15 11:17         ` Neil Jerram
  2005-10-15 11:24       ` Neil Jerram
  1 sibling, 1 reply; 55+ messages in thread
From: Andreas Rottmann @ 2005-10-14  1:28 UTC (permalink / raw)


Greg Troxel <gdt@ir.bbn.com> 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)
>   that does
>
>        guile-config add-load-path mydata $(datadir)/guile "My Location"
>
>   Am I still missing something?
>
> No, you're not - that's just fine, and would be IMHO the 'standard
> way' to do things, or at least one of two ways, with the other
> probably being putting stuff in $(guile-prefix)/share/guile.
>
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 installed there.

-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Could Jesus microwave a burrito so hot that he himself couldn't eat it? 
    - Homer S.



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-13 18:21 Modified load-path proposal Neil Jerram
  2005-10-13 18:40 ` Greg Troxel
@ 2005-10-14  7:24 ` Ludovic Courtès
  2005-10-15 11:55   ` Neil Jerram
  1 sibling, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-10-14  7:24 UTC (permalink / raw)
  Cc: Guile Users

Hi,

Neil Jerram <neil@ossau.uklinux.net> 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 Guile version are an exception rather than the
rule (well, in fact, pure Scheme modules may be quite portable across
versions).

As for the tag tuples, I'd prefer either an alist, the use of keywords,
or maybe a vector---it just feels more ``natural'' when representing
such ``records'', IMO.  But I guess that's just a matter of taste.

Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-14  1:28       ` Andreas Rottmann
@ 2005-10-15 11:17         ` Neil Jerram
  2005-10-15 15:03           ` Greg Troxel
  2005-10-22 23:16           ` Kevin Ryde
  0 siblings, 2 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-15 11:17 UTC (permalink / raw)
  Cc: guile-user

Andreas Rottmann <a.rottmann@gmx.at> 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 installed there.

Fundamentally, however, it's up to the package author, and autoconf
provides no way to police this.

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.  Does that annoy you also?

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

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-14  0:37     ` Greg Troxel
  2005-10-14  1:28       ` Andreas Rottmann
@ 2005-10-15 11:24       ` Neil Jerram
  2005-10-15 15:01         ` Greg Troxel
  1 sibling, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-15 11:24 UTC (permalink / raw)
  Cc: Guile Users

Greg Troxel <gdt@ir.bbn.com> 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 your proposal.

Thanks.  I thought of one more detail that I think I did miss,
however: someone distributing Guile would not do a "make install",
they'd do a "make dist" or "make deb" instead.  So there needs to be a
way to customize the contents of config.scm before the "make
dist/deb", without config.scm having been installed.

       Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-14  7:24 ` Ludovic Courtès
@ 2005-10-15 11:55   ` Neil Jerram
  2005-10-15 15:40     ` Greg Troxel
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-15 11:55 UTC (permalink / raw)


ludovic.courtes@laas.fr (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, agreed ...

> (well, in fact, pure Scheme modules may be quite portable across
> versions).

... but that's a good point too!

Perhaps this means that Greg's cross-product idea is right after all.

(In other words, that %load-path is constructed from all possible
combinations of a set of roots, e.g. '("/usr/share/guile"
"/usr/local/share/guile") and a set of suffix directories,
e.g. '("site" "1.6" "").)

A package could declare whether (it thinks) it is portable or
version-dependent by a argument to the GUILE_SCHEME_DIR macro, and
GUILE_SCHEME_DIR would then return the appropriate install location.

> As for the tag tuples, I'd prefer either an alist, the use of keywords,
> or maybe a vector---it just feels more ``natural'' when representing
> such ``records'', IMO.  But I guess that's just a matter of taste.

Taste and simplicity, yes.  I'm wondering if my currently proposed
format is too fussy.  Do we really need the descriptions and the tags?
The descriptions don't really add much that can't be inferred from the
directories themselves.  The only benefit of the tags is that a
distributor can write --with-guile-scheme-dir=tag instead of
--with-guile-scheme-dir=/some/install/path when running ./configure,
which is probably not enough to justify the cost of having to think up
a tag when running guile-config add-load-path.

If we get rid of the descriptions and tags, the format could be
simplified to something like this:

((load-path
  "/usr/share/guile/1.6"
  "/usr/share/guile/site"
  "/opt/gnome/guile"
  ("/usr/local/share/guile" #:package-default)
  "/usr/local/share/guile/1.6"))

(And with Greg's cross-product idea, it would simplify even further.)

What do you think?

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-15 11:24       ` Neil Jerram
@ 2005-10-15 15:01         ` Greg Troxel
  2005-10-15 17:49           ` Neil Jerram
  0 siblings, 1 reply; 55+ messages in thread
From: Greg Troxel @ 2005-10-15 15:01 UTC (permalink / raw)
  Cc: Guile Users

Neil Jerram <neil@ossau.uklinux.net> writes:

> Greg Troxel <gdt@ir.bbn.com> 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 your proposal.
> 
> Thanks.  I thought of one more detail that I think I did miss,
> however: someone distributing Guile would not do a "make install",
> they'd do a "make dist" or "make deb" instead.  So there needs to be a
> way to customize the contents of config.scm before the "make
> dist/deb", without config.scm having been installed.

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 some sort is tarred up from
there, or it's installed first and then tarred up (pkgsrc) won't matter.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  1 sibling, 1 reply; 55+ messages in thread
From: Greg Troxel @ 2005-10-15 15:03 UTC (permalink / raw)
  Cc: Andreas Rottmann, guile-user

  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 this is the crux of the disagreement.  I, and I think Andreas,
feel that putting stuff in a different prefix is somewhere between
wrong and inelegant.  Guile will have a way to reference code outside
of it's prefix, so it will still be seamless, so the kludge of putting
lisp code built with a prefix different from that of emacs in emacs'
prefix isn't necessary.  So I'd like the core distribution to at least
be neutral on what the 'right' way is, and explain both
in-guile's-prefix and in-the-prefix-that-was-given methods.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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 18:10       ` Neil Jerram
  0 siblings, 2 replies; 55+ messages in thread
From: Greg Troxel @ 2005-10-15 15:40 UTC (permalink / raw)
  Cc: Guile Users

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 slib on
    NetBSD pkgsrc (symlink to /usr/pkg/share/slib) and slibcat file.

$(guileprefix)/share/guile/site

    unclear why this is used rather than above, unless it's for
    sysadmin-managed stuff within guile's prefix rather than
    pkg-managed.  On NetBSD pkgsrc database (ttn's guile-pg) lives
    here.

$(guileprefix)/share/guile/1.6

    Currently, stuff that is actually part of guile; I haven't seen
    other packages install stuff here.

$(otherprefix)/share/guile

   probably where to put generic non-pkg-managed stuff, although that
   raises the issue of why a different prefix was used, but pkg
   systems may want to do this

$(otherprefix)/share/guile/site

   non-pkg-managed stuff, done by group sysadmin.  But, it seems
   likely that the use of otherprefix serves the purpose of site.

A related point is whether it is ok to install two versions of guile
in the same prefix.  It seems that at least some things conflict, and
this really doesn't work.  NetBSD pkgsrc has support for 1.4 and 1.6
at the moment, with 1.6 default and 1.4 as guile14.  guile14 is built
with /usr/pkg/guile/1.4, so it's in a totally different place, and
things that use it (not too many now) link there.

So, if we can't install two guiles in the same prefix (which is fine;
prefixes are fairly cheap), then it makes sense to declare that the
1.6 subdir is for things that are part of guile (meaning built from
the distribution).  Packages built against 1.6 would record a
dependency, and you'd expect to have to rebuild them or get a version
built against 1.8 later, just like packages built against anything
else with a possibly changing ABI.

Also, it could well be that the whole 'site' notion is outdated.  This
made sense back in the days of 4.3BSD, but with packaging systems
doesn't so much, especially since the right thing to do is to have a
separate prefix from the packaging system.

So, my proposal is:

  $(guileprefix)/share/guile

     This is where pkg-managed modules should go.

     Those that think it is reasonable for programs configured with
     other prefixes should put them here, unless their package system
     says they should somehow keep non-pkg-managed stuff separate.

  $(guileprefix)/share/guile/site

      Historic/deprecated.  Created by guile, but nothing put in it.

      If someone is using non-pkg-managed stuff across multiple
      machines, perhaps they should put it here.

      If someone is using non-pkg-managed programs, but using the 'put
      in guile's prefix' approach, perhaps all that stuff can go here
      so the non-managed stuff (viewed as turds by things like
      pkg_admin check to find unregistered files) will all be in one
      place.  Thus this should perhaps be the default for macros
      called to ask for guile's prefix.

  $(guileprefix)/share/guile/1.6

      As it is now: files that are part of guile.  Others are strongly
      discouraged from putting anything there.


  $(guileprefix)/share/guile/local

      This would be like the old local vs. site.  There seems to be
      little need.  The 'add arbitrary dirs' scheme would support
      this, but guile should just ignore this and not mention it or
      put it in my default.

  $(otherprefix)/share/guile

      This is where I'd put modules installed aftetr configuring for
      another prefix.  Whether this is site or local can be encoded in
      otherprefix.  Adding a 1.6/1.8 dir won't fully solve the API/ABI
      compat issue, and doing it halfway will lead to trouble


Then, the GUILE_SCHEME_DIR macro should take a token which is either

  guile-prefix
  own-prefix

and return one of (depending on how we feel about protecting pkg
systems from people who want to install non-managed stuff in them)

  $(guileprefix)/share/guile
  $(guileprefix)/share/guile/site

or

  $(otherprefix)/share/guile


Optionally, one should be able to specify either a replacement for
share/guile or further components, perhaps when using either
guile-prefix or own-prefix, and this should then generate or enable
code to hook the dir into guile's load-path at make install time.

So, I think my cross-product idea was not so good - the current 3
places are a bit messy/historic rather than really the right thing to
do.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-15 15:01         ` Greg Troxel
@ 2005-10-15 17:49           ` Neil Jerram
  0 siblings, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-15 17:49 UTC (permalink / raw)
  Cc: Guile Users

Greg Troxel <gdt@ir.bbn.com> 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 some sort is tarred up from
> there, or it's installed first and then tarred up (pkgsrc) won't matter.

Yes, agreed on both points.

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-15 15:03           ` Greg Troxel
@ 2005-10-15 17:53             ` Neil Jerram
  0 siblings, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-15 17:53 UTC (permalink / raw)
  Cc: Andreas Rottmann, guile-user

Greg Troxel <gdt@ir.bbn.com> 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 different from the add-on package's $prefix).
>
> I think this is the crux of the disagreement.

Yes, I agree (that this is the crux), but it's not in our control to
force package authors to abide by this, even if we agreed to adopt
this as policy.

> So I'd like the core distribution to at least
> be neutral on what the 'right' way is, and explain both
> in-guile's-prefix and in-the-prefix-that-was-given methods.

I'm happy with that.

    Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-15 15:40     ` Greg Troxel
@ 2005-10-17  8:04       ` Ludovic Courtès
  2005-10-17 17:52         ` Greg Troxel
  2005-10-17 17:54         ` Modified load-path proposal Neil Jerram
  2005-10-17 18:10       ` Neil Jerram
  1 sibling, 2 replies; 55+ messages in thread
From: Ludovic Courtès @ 2005-10-17  8:04 UTC (permalink / raw)
  Cc: Guile Users, Neil Jerram

Hi,

Greg Troxel <gdt@ir.bbn.com> 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 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 systems do provide an important
installation pattern that has to be made possible to use.

Looking at your proposal, I don't see why modules installed by a
packaging system would end up in a different directory than modules
installed "by hand".  When I install a C program, whether "I" really
refers to me or to a packaging system, I can specify installation
directories with a very fine grain.

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 sure there's a way for Guile to
know about them.  The good thing is that this is policy-neutral.

I guess the Guile-specific installation directories, for any given Guile
module set (I'm not talking about modules that come with Guile), are:

  - `guileschemedir', which is where Guile Scheme source files should
    get installed; by default, this could be
    `/usr/share/guile/MAJOR.MINOR';

  - `guilelibdir', which is where C libraries (glue code, wrappers,
    etc.) that come with a module should go; by default, this could be
    `/usr/local/lib';

  - `guileobjectdir', which is where we'd put byte-compiled code if we
    had a working VM.  ;-)

At `make install'-time, we'd still need to use a mechanism like the one
Neil proposed in order to `add-load-path $(guileschemedir)'.  We might
actually want to do this also for C libraries.  [BTW, Neil's proposed
`config.scm' is not unlike `ld.so.conf' (or equivalent) for C code.]

>From the user's view point, this wouldn't be any different from what is
done when installing C programs:

  $ ./configure --bindir=/usr/bin --guileschemedir=/there \
                --guilelibdir=/usr/share/lib/guile/2.3

In summary, if we look at Neil's `config.scm', it really cares about
`guileschemedir' (or `load-path'), and that's it.  So it might be
possible to make it contain just a simple list of directories.

OTOH, it might be a good idea to make it aware of `guilelibdir'.  This
way, if Guile is able to load a `.scm' file, it would _always_ be able
to load the shared object it opens via `dynamic-link', no matter what
LTDL_LIBRARY_PATH and friends look like.

Hope this makes some sense,
Ludovic.

[0] http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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-17 17:54         ` Modified load-path proposal Neil Jerram
  1 sibling, 1 reply; 55+ messages in thread
From: Greg Troxel @ 2005-10-17 17:52 UTC (permalink / raw)
  Cc: Guile Users, Neil Jerram

ludovic.courtes@laas.fr (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 systems do provide an important
> installation pattern that has to be made possible to use.

The point is that package systems demand exclusive access, and this is
on of the reasons to use multiple prefixes.

> I guess the Guile-specific installation directories, for any given Guile
> module set (I'm not talking about modules that come with Guile), are:
> 
>   - `guileschemedir', which is where Guile Scheme source files should
>     get installed; by default, this could be
>     `/usr/share/guile/MAJOR.MINOR';

It's not clear why this but not libdir should be versioned.

>   - `guilelibdir', which is where C libraries (glue code, wrappers,
>     etc.) that come with a module should go; by default, this could be
>     `/usr/local/lib';

arguably should be $(prefix)/lib/guile to keep from polluting lib.

>   - `guileobjectdir', which is where we'd put byte-compiled code if we
>     had a working VM.  ;-)

this belongs under share, since it's machine independent.


> OTOH, it might be a good idea to make it aware of `guilelibdir'.  This
> way, if Guile is able to load a `.scm' file, it would _always_ be able
> to load the shared object it opens via `dynamic-link', no matter what
> LTDL_LIBRARY_PATH and friends look like.

Perhaps dynamic-link should look in guilelibdir _only_ if an absolute
path is not given, or a primitive that does this.  One important
feature is that inclusion, dynamic link, etc. should be able to ensure
it gets exactly what was searched for and tested at configure time.


-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-17  8:04       ` Ludovic Courtès
  2005-10-17 17:52         ` Greg Troxel
@ 2005-10-17 17:54         ` Neil Jerram
  2005-10-18  7:57           ` Ludovic Courtès
  1 sibling, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-17 17:54 UTC (permalink / raw)
  Cc: Guile Users

ludovic.courtes@laas.fr (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 sure there's a way for Guile to
> know about them.  The good thing is that this is policy-neutral.

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 for load-path!

       Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-15 15:40     ` Greg Troxel
  2005-10-17  8:04       ` Ludovic Courtès
@ 2005-10-17 18:10       ` Neil Jerram
  2005-10-18 16:16         ` Greg Troxel
  1 sibling, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-17 18:10 UTC (permalink / raw)
  Cc: Guile Users

Greg Troxel <gdt@ir.bbn.com> 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 described is mostly policy,
whereas I'm interested right now in the mechanism.

That said, mechanism and policy are obviously dependent in at least 3
ways.

1. There has to be a set of defaults, which is policy.

2. Likely policies can help us decide what mechanism will be useful.

3. Policy examples are useful for documenting the mechanism.

So, to summarize how what I think you are saying relates to these
points ...

1. Regardless of possibly more rational arguments (e.g. what on earth
   is "site" for?), I think the defaults have to be back-compatible.
   That means they have to be ("${prefix}/share/guile/site"
   "${prefix}/share/guile/1.6" "${prefix}/share/guile").

2. I think your arguments about how parallel distributions may be
   installed are strong enough to dismiss the cross-product idea.

   I don't see any benefit of GUILE_SCHEME_DIR taking an own-prefix
   argument; in this case the package author can just hardcode
   own-prefix in their Makefile.am.

   I'd like to leave the decision to the distributor on exactly where
   installation under Guile's prefix should go - whether guile,
   guile/site or guile/1.6.  I think I'd make the default guile/site,
   but I'm not much bothered.

3. I shall keep your email around for when it comes to documenting all
   this - thanks!

Regards,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  0 siblings, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-10-18  7:57 UTC (permalink / raw)
  Cc: Guile Users

Hi,

Neil Jerram <neil@ossau.uklinux.net> 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 for load-path!

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 directory
    (which you seem to be assuming when talking about
    `GUILE_SCHEME_DIR').

    The mechanism you proposed is _needed_ to allow Guile to play well
    with Scheme source files installed in various directories -- in
    other words, your mechanism must translate various installation-time
    values of `guileschemedir' into a suitable run-time value of
    `%load-path'.  Your proposal is alright for this.

2.  While we're at it, we might want to use your mechanism as well for
    shared objects.


(1) is really crucial I think.  (2) can be thought about later on.

Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Search path for C libraries
  2005-10-17 17:52         ` Greg Troxel
@ 2005-10-18  8:23           ` Ludovic Courtès
  2005-10-18 10:12             ` Vorfeed Canal
  0 siblings, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-10-18  8:23 UTC (permalink / raw)
  Cc: Guile Users, Neil Jerram

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> Perhaps dynamic-link should look in guilelibdir _only_ if an absolute
> path is not given, or a primitive that does this.  One important
> feature is that inclusion, dynamic link, etc. should be able to ensure
> it gets exactly what was searched for and tested at configure time.

Right.  This is one of the concerns that was raised by Vorfeed Canal
earlier I think.

Maybe the right way to do this would in fact to have module developers
generate the `dynamic-link' code at configure-time (using Autoconf
substitution) in order to hard-wire the library path.  Unfortunately,
this isn't very elegant and it precludes, for instance, running the
module's test suite before installing it (because `dynamic-link' would
either fail or load the wrong library).

This is why extending Neil's mechanism to C libraries might help here.

Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Search path for C libraries
  2005-10-18  8:23           ` Search path for C libraries Ludovic Courtès
@ 2005-10-18 10:12             ` Vorfeed Canal
  0 siblings, 0 replies; 55+ messages in thread
From: Vorfeed Canal @ 2005-10-18 10:12 UTC (permalink / raw)


On 10/18/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
> Hi,
>
> Greg Troxel <gdt@ir.bbn.com> writes:
>
> > Perhaps dynamic-link should look in guilelibdir _only_ if an absolute
> > path is not given, or a primitive that does this.  One important
> > feature is that inclusion, dynamic link, etc. should be able to ensure
> > it gets exactly what was searched for and tested at configure time.
>
> Right.  This is one of the concerns that was raised by Vorfeed Canal
> earlier I think.
>
Yup. This is EXACTLY why libltdl have search_path in first place. Of
course libltdl WILL NOT try to use this path if full path is given in
load-extension - this is all built in ltdl:
http://www.gnu.org/software/libtool/manual.html#Using-libltdl

In my patch I moved search_path to scheme level and when dynamic
loaded is used old ltdl search_path will be forgotten. Since guile is
designed to be used in big, complex programs perhaps its better to
save search path and then restore it. And this must be done under 
lt_dlmutex_lock/lt_dlmutex_unlock, obviously.

I left all this out of patch since this was proof-of-concept kinda
thing anyway and since before guile 1.8 release someone should do
something with this:

-- guile-1.7.2/libguile/dynl.c
/*
  From the libtool manual: "Note that libltdl is not threadsafe,
  i.e. a multithreaded application has to use a mutex for libltdl.".

  Guile does not currently support pre-emptive threads, so there is no
  mutex.  Previously SCM_CRITICAL_SECTION_START and
  SCM_CRITICAL_SECTION_END were used: they are mentioned here in case
  somebody is grepping for thread problems ;)
*/
-- cut --
Libtool manual does not say this anymore:
http://www.gnu.org/software/libtool/manual.html#Thread-Safety-in-libltdl
and guile DOES have support for pre-emptive threads now so it's good
idea to do something about this.

This is separate problem and there are not much to discuss: ltdl can
not be used in multi-threaded environment without
lt_dlmutex_lock/lt_dlmutex_unlock (it changes global variable
search-path internally, for example!) and while you can export ltdl's
variable to scheme level "as is" you'll be forced to export
LT_PATHSEP_CHAR as well and then every scheme module will be exposed
to gory details of OS dynamic loading mechanism (":" vs ";") so it all
will look quite ugly (barely better then current way of parsing and
changing of LD_LIBRARY_PATH/LTDL_LIBRARY_PATH).

> Maybe the right way to do this would in fact to have module developers
> generate the `dynamic-link' code at configure-time (using Autoconf
> substitution) in order to hard-wire the library path.

It can be done already, but most distribution's HOWTOs are quite vocal
about never using -rpath with C libraries - and this is the same
thing.

> Unfortunately, this isn't very elegant and it precludes, for instance, running the
> module's test suite before installing it (because `dynamic-link' would
> either fail or load the wrong library).

This is one reason, yes.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  0 siblings, 2 replies; 55+ messages in thread
From: Greg Troxel @ 2005-10-18 16:16 UTC (permalink / raw)
  Cc: Guile Users

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 sane behavior to avoid future messes to be
backwards-compat with.
-- 
        Greg Troxel <gdt@ir.bbn.com>


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-18 16:16         ` Greg Troxel
@ 2005-10-18 21:24           ` Vorfeed Canal
  2005-10-19 22:29           ` Neil Jerram
  1 sibling, 0 replies; 55+ messages in thread
From: Vorfeed Canal @ 2005-10-18 21:24 UTC (permalink / raw)


On 18 Oct 2005 12:16:05 -0400, Greg Troxel <gdt@ir.bbn.com> 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 sufficient for various policies is the key point, but think
> we also need to suggest sane behavior to avoid future messes to be
> backwards-compat with.

Why not just use Python way ?
/usr/share/guile-1.6/site - for third-party packages
/usr/share/guile-1.6 - for basic guile packages

Right now GUILE_SITE_DIR is defined as

AC_DEFUN([GUILE_SITE_DIR],
 [AC_REQUIRE([GUILE_PROGS])dnl
 AC_MSG_CHECKING(for Guile site directory)
 GUILE_SITE=`[$GUILE_CONFIG] info pkgdatadir`/site
 AC_MSG_RESULT($GUILE_SITE)
 AC_SUBST(GUILE_SITE)
 ])

This means existing packages will install into <somewhere>/site no
matter what - it's too late to change it.

P.S. This is why I think this stuff is important and was actually
dumbfound when found it's not solved yet for C libraries: this IS
policy. More: it's policy embedded in thousands of places (today may
be in tens, not thousands - but this is only since few people are
interested in guile and its extensions and this problem, not a
solution). It's almost impossible to change it later: whatever will be
decided will stuck for a long-long time.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-18 16:16         ` Greg Troxel
  2005-10-18 21:24           ` Vorfeed Canal
@ 2005-10-19 22:29           ` Neil Jerram
  1 sibling, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-19 22:29 UTC (permalink / raw)
  Cc: Guile Users

Greg Troxel <gdt@ir.bbn.com> 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 the key point, but think
> we also need to suggest sane behavior to avoid future messes to be
> backwards-compat with.

OK.  We can do this by a combination of (i) setting the default so
that 3rd party stuff doesn't go under 1.6, (ii) providing a note on
this point for distributors (new top level DISTRIBUTION file?).

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  0 siblings, 2 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-19 22:30 UTC (permalink / raw)


ludovic.courtes@laas.fr (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 directory
>     (which you seem to be assuming when talking about
>     `GUILE_SCHEME_DIR').
>
>     The mechanism you proposed is _needed_ to allow Guile to play well
>     with Scheme source files installed in various directories -- in
>     other words, your mechanism must translate various installation-time
>     values of `guileschemedir' into a suitable run-time value of
>     `%load-path'.  Your proposal is alright for this.
>
> 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).

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-19 22:30             ` Neil Jerram
@ 2005-10-20  7:56               ` Vorfeed Canal
  2005-10-20  8:05               ` Ludovic Courtès
  1 sibling, 0 replies; 55+ messages in thread
From: Vorfeed Canal @ 2005-10-20  7:56 UTC (permalink / raw)


On 10/20/05, Neil Jerram <neil@ossau.uklinux.net> wrote:
> ludovic.courtes@laas.fr (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 not differ. It's just a reminder: if module loading
code in guile will be changed it's important to not forget about
guilelibdir change as well. Right now we have something which

1. Have practical problems (discussed in separate thread).
2. Is totally different from the way scheme modules are handled.
3. Is totally different from the way other scripting languages
(perl,php,python,ruby,etc) are doing it.

When modules loading mechanism is changing it's good time to make the
same changes in load-extension mechanism as well to make everything
consistent.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  1 sibling, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-10-20  8:05 UTC (permalink / raw)
  Cc: Guile Users

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (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 directory
>>     (which you seem to be assuming when talking about
>>     `GUILE_SCHEME_DIR').
>>
>>     The mechanism you proposed is _needed_ to allow Guile to play well
>>     with Scheme source files installed in various directories -- in
>>     other words, your mechanism must translate various installation-time
>>     values of `guileschemedir' into a suitable run-time value of
>>     `%load-path'.  Your proposal is alright for this.

> 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* installation
directory: the one were Scheme files will go.  In your scheme (as I
understand it), the other directories (the one for shared objects in
particular) are *imposed*: the user cannot change them.

What I'm saying in (1) is that the user should be able to choose these
two (or three) directories at installation time.

Thanks,
Ludovic.



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-20  8:05               ` Ludovic Courtès
@ 2005-10-20 22:23                 ` Neil Jerram
  2005-10-21  7:59                   ` Ludovic Courtès
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-20 22:23 UTC (permalink / raw)


ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Neil Jerram <neil@ossau.uklinux.net> 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* installation
> directory: the one were Scheme files will go.  In your scheme (as I
> understand it), the other directories (the one for shared objects in
> particular) are *imposed*: the user cannot change them.
>
> 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 location debate yet, because I know very little about libtool and
other aspects of the issue, and because I believe that other Guile
developers believe that there are good reasons for the status quo.
Also it seems very unlikely that the outcome of that debate would
affect the details of a GUILE_SCHEME_DIR macro.

You're welcome to continue that debate, of course, but to be honest
it's probably better to wait until Marius and/or Rob have bandwidth to
describe the problems that they see with Vorfeed's "obvious" solution.

Regards,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-20 22:23                 ` Neil Jerram
@ 2005-10-21  7:59                   ` Ludovic Courtès
  0 siblings, 0 replies; 55+ messages in thread
From: Ludovic Courtès @ 2005-10-21  7:59 UTC (permalink / raw)
  Cc: Guile Users

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (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 location debate yet, because I know very little about libtool and
> other aspects of the issue, and because I believe that other Guile
> developers believe that there are good reasons for the status quo.
> Also it seems very unlikely that the outcome of that debate would
> affect the details of a GUILE_SCHEME_DIR macro.

Again, I was not saying that Guile should provide a mechanism to load
shared objects from the right directory: we have identified this as
another, *separate* issue.  I'm just saying that libraries and Scheme
files are two different things and that the user needs to be able to
choose where to install them, just like they can do for any other GNU
package.

Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-15 11:17         ` Neil Jerram
  2005-10-15 15:03           ` Greg Troxel
@ 2005-10-22 23:16           ` Kevin Ryde
  2005-10-28 17:45             ` Neil Jerram
  1 sibling, 1 reply; 55+ messages in thread
From: Kevin Ryde @ 2005-10-22 23:16 UTC (permalink / raw)
  Cc: guile-user

Neil Jerram <neil@ossau.uklinux.net> 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 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
	$libdir/xemacs/site-lisp
	$datadir/emacs/site-lisp
	$datadir/xemacs/site-lisp

according to whether $EMACS load-path has /something/lib or
/something/share, and whether it's emacs or xemacs.

Ie. it always respects your $prefix, the choice is just what subdir of
there.  You'd be hard pressed to tell that from the doco though :-(.

I presume lib vs share is just about historical filesystem layout.
Byte code is machine-independent so no doubt share is the right place
these days.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-22 23:16           ` Kevin Ryde
@ 2005-10-28 17:45             ` Neil Jerram
  2005-10-30 18:04               ` Neil Jerram
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-28 17:45 UTC (permalink / raw)
  Cc: guile-user

Kevin Ryde <user42@zip.com.au> 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
> 	$libdir/xemacs/site-lisp
> 	$datadir/emacs/site-lisp
> 	$datadir/xemacs/site-lisp
>
> according to whether $EMACS load-path has /something/lib or
> /something/share, and whether it's emacs or xemacs.

Thanks for the heads up.  I've looked at the AM_PATH_LISPDIR code now
and agree that you're right.

Together with the history that shows up if you google for
AM_PATH_LISPDIR, this suggests that Greg's and Ludovic's preference
for things only being installed under $prefix was right all along.

And if we go with that it also makes everything much simpler.

- We no longer need the idea that the distribution or Guile
  installation has a preference for where 3rd party packages should
  go, so the `default' marker in config.scm can disappear.

- Therefore we don't need the GUILE_SCHEME_DIR macro.

- Therefore we don't need tags or descriptions.

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 config.scm on startup, as previously described
  (and respecting $sysconfdir)

- guile-config ensure-load-path and guile-config clean-load-path, for
  use at package author's discretion in Makefile.am.

Everyone happy with that?

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-28 17:45             ` Neil Jerram
@ 2005-10-30 18:04               ` Neil Jerram
  2005-10-30 18:15                 ` Tomas Zerolo
                                   ` (3 more replies)
  0 siblings, 4 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-30 18:04 UTC (permalink / raw)


Neil Jerram <neil@ossau.uklinux.net> 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 config.scm on startup, as previously described
>   (and respecting $sysconfdir)
>
> - guile-config ensure-load-path and guile-config clean-load-path, for
>   use at package author's discretion in Makefile.am.
>
> Everyone happy with that?

Well, I'm not sure I am.  This is still not quite nice, in that (i)
editing config.scm when a 3rd party package is installed or removed is
not as neat as just creating or deleting a file in an init.d style
directory; (ii) there's no trace of why a load path directory is
present in config.scm, i.e. which packages are relying on it.

I've reviewed everything I'm aware of that's been written on this
subject, starting from Marius's and Rob's original proposal at
http://lists.gnu.org/archive/html/guile-devel/2004-11/msg00016.html,
and I'm finally inclined to think that an init.d approach is nicer
than a config.scm file that can be automatically edited.

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, when a package
guile-foo is installed under $prefix, it would create the file
$sysconfdir/guile/X.Y/init.d/guile-foo with contents:

(require-load-path-directory "$prefix/wherever/my/scheme/files/are")

There was consensus in the previous discussion that a package should
not do anything in such files except for load path modification.  We
could enforce this by making the contents instead:

"$prefix/wherever/my/scheme/files/are"

and making init.scm read the file instead of loading it, but that
would mean that if we ever do think of something else that the init.d
files should be able to do, we'd have to enhance the whole mechanism
again.  On balance I think it's best to load the init.d files (hence
theoretically allowing arbitrary code) but make it clear by
documentation/convention that only load path extension is expected.

In comparison with the config.scm idea, the advantages are that you
can immediately see from the contents of the init.d directory which
packages are relying on particular load path directories (and, from
the free software point of view, you can see where to go to find the
scheme files for guile-foo), that there is no need for a heuristic to
decide when to remove a directory, and that creating or deleting an
init.d file is similar to what packaging systems already do when
installing an add-on for other subsystems.

Some other details from the past discussions ...

1. Whether init.scm is seen as belonging to Guile, to the
   distribution, or to the local sysadmin.

   It would be nice to put most of the code for the init.d system into
   boot-9.scm (or a file that boot-9.scm loads), so that init.scm can
   have just a one-liner which makes it all happen.  (If we want to
   get sophisticated, there could be options to this one-liner to
   exclude the processing of particular packages, or to limit the set
   of packages that is processed to a named set, or to force an
   ordering ...)

   Then I think it is easy for either the distribution or the sysadmin
   to tweak init.scm as they need, but still clear how to get the
   "standard" Guile behaviour.

2. An option for suppressing the loading of init.scm.

   It seems straightforward that this is a good idea, like
   --no-site-file in Emacs.  (Note that more finegrained selection -
   i.e. "run this part of init.scm but not that part" - can be
   implemented within the code of init.scm itself, if that is ever
   useful.)

3. Reading from $sysconfdir/guile/common/init.d as well as
   $sysconfdir/guile/X.Y/init.d, for packages that are not dependent
   on a particular Guile version.

   Seems like a good idea also.  We could make the default one-liner
   invocation do this, put provide an option for more precise control
   if the distribution or sysadmin needs it.

Finally, to be concrete about how this would end up looking in a 3rd
party package's files, I think it would be something like this:

---8<---guile-foo.in---8<---
(require-load-path-directory "@-datadir-@/guile")
---8<---guile-foo.in---8<---

---8<---Makefile.am---8<---
...
guileinitdir = @guileconfdir@/@GUILE_EFFECTIVE_VERSION@/init.d
guileinit_DATA = guile-foo

guile-foo: guile-foo.in
	sed -e "s,@-datadir-@,@datadir@,g" < $< > $@
...
---8<---Makefile.am---8<---

And some autoconfery would be needed to make @guileconfdir@ expand to
`guile-config info sysconfdir`/guile.

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

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-30 18:04               ` Neil Jerram
@ 2005-10-30 18:15                 ` Tomas Zerolo
  2005-10-30 20:37                 ` Thien-Thi Nguyen
                                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 55+ messages in thread
From: Tomas Zerolo @ 2005-10-30 18:15 UTC (permalink / raw)
  Cc: guile-user


[-- Attachment #1.1: Type: text/plain, Size: 610 bytes --]

On Sun, Oct 30, 2005 at 06:04:58PM +0000, Neil Jerram wrote:
> Neil Jerram <neil@ossau.uklinux.net> 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 direction a couple of times.  If anyone is still reading, I'd
> appreciate hearing your thoughts (again).

Neil, you rock :-)))

(and no, there's not a bit of irony here).

I do like your proposal of an init.d directory. It'll make distributor's
lives much easier.

Thanks
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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 13:17                   ` Tomas Zerolo
  2005-10-30 23:48                 ` Kevin Ryde
  2005-11-02  8:44                 ` Ludovic Courtès
  3 siblings, 2 replies; 55+ messages in thread
From: Thien-Thi Nguyen @ 2005-10-30 20:37 UTC (permalink / raw)
  Cc: guile-user

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: Sun, 30 Oct 2005 18:04:58 +0000

   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 third-party-programmer's shoes from
the beginning.  perlis sez: simplicty follows complexity.

thi


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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 13:17                   ` Tomas Zerolo
  1 sibling, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-30 22:59 UTC (permalink / raw)
  Cc: guile-user

Thien-Thi Nguyen <ttn@glug.org> writes:

>    From: Neil Jerram <neil@ossau.uklinux.net>
>    Date: Sun, 30 Oct 2005 18:04:58 +0000
>
>    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.

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, someone will want to change it to be more permissive in future?

>  you might as well
> put yourself in the third-party-programmer's shoes from
> the beginning.  perlis sez: simplicty follows complexity.

perlis?

        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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 23:48                 ` Kevin Ryde
  2005-10-31 13:20                   ` Tomas Zerolo
  2005-10-31 19:20                   ` Neil Jerram
  2005-11-02  8:44                 ` Ludovic Courtès
  3 siblings, 2 replies; 55+ messages in thread
From: Kevin Ryde @ 2005-10-30 23:48 UTC (permalink / raw)


Neil Jerram <neil@ossau.uklinux.net> 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, when a package
> guile-foo is installed under $prefix, it would create the file
> $sysconfdir/guile/X.Y/init.d/guile-foo with contents:
>
> (require-load-path-directory "$prefix/wherever/my/scheme/files/are")

What advantage is this over putting a symlink in /usr/share/guile/site
to point to this alternate location?

What is the wherever/my/scheme/files/are directory likely to be?
Guile library packages wouldn't be sprayed randomly across all four
corners of the disk would they?


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-30 22:59                   ` Neil Jerram
@ 2005-10-31 10:55                     ` Thien-Thi Nguyen
  2005-10-31 19:22                       ` Neil Jerram
  0 siblings, 1 reply; 55+ messages in thread
From: Thien-Thi Nguyen @ 2005-10-31 10:55 UTC (permalink / raw)
  Cc: guile-user

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: Sun, 30 Oct 2005 22:59:32 +0000

   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, someone will want to change it to be more permissive in future?

both interpretations are fine.

   perlis?

google?

thi


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-30 20:37                 ` Thien-Thi Nguyen
  2005-10-30 22:59                   ` Neil Jerram
@ 2005-10-31 13:17                   ` Tomas Zerolo
  1 sibling, 0 replies; 55+ messages in thread
From: Tomas Zerolo @ 2005-10-31 13:17 UTC (permalink / raw)
  Cc: guile-user, neil


[-- Attachment #1.1: Type: text/plain, Size: 583 bytes --]

On Sun, Oct 30, 2005 at 03:37:33PM -0500, Thien-Thi Nguyen wrote:
>    From: Neil Jerram <neil@ossau.uklinux.net>
>    Date: Sun, 30 Oct 2005 18:04:58 +0000
> 
>    We could enforce this by [...]
>    I'd appreciate hearing your thoughts (again).
> 
> if your design requires enforcement, [...]

Neil considered enforcement, but dismissed it in favor of convention.
That's one fo the things I liked about his proposal.

perlis sez: simplicty follows complexity.

That seems to be THE Alan Perlis (in response to a question later in the
thread).

Regards
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-30 23:48                 ` Kevin Ryde
@ 2005-10-31 13:20                   ` Tomas Zerolo
  2005-10-31 19:20                   ` Neil Jerram
  1 sibling, 0 replies; 55+ messages in thread
From: Tomas Zerolo @ 2005-10-31 13:20 UTC (permalink / raw)
  Cc: guile-user


[-- Attachment #1.1: Type: text/plain, Size: 800 bytes --]

On Mon, Oct 31, 2005 at 10:48:43AM +1100, Kevin Ryde wrote:
> Neil Jerram <neil@ossau.uklinux.net> 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 thing provides: there is a
place where the third-party package can put bits of knowledge about its
installation the sysadmin can look into (a symlink is too small :)

> What is the wherever/my/scheme/files/are directory likely to be?
> Guile library packages wouldn't be sprayed randomly across all four
> corners of the disk would they?

Well, no -- but it's likely that different distros have diverging ideas
about where third-party guile-using packages go.

Regards
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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-01 23:31                     ` Vorfeed Canal
  1 sibling, 2 replies; 55+ messages in thread
From: Neil Jerram @ 2005-10-31 19:20 UTC (permalink / raw)
  Cc: guile-user

Kevin Ryde <user42@zip.com.au> 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 installed with one
  prefix wants to install (database mysql) and a different package
  with a different prefix wants to install (database postgres)

- in my view, installing an init.d file (under $sysconfdir) feels less
  polluting of the distribution-managed part of the filesystem than
  putting a symlink into /usr/share/guile/site.

> What is the wherever/my/scheme/files/are directory likely to be?
> Guile library packages wouldn't be sprayed randomly across all four
> corners of the disk would they?

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?

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-31 10:55                     ` Thien-Thi Nguyen
@ 2005-10-31 19:22                       ` Neil Jerram
  2005-11-08 12:37                         ` Thien-Thi Nguyen
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-10-31 19:22 UTC (permalink / raw)
  Cc: guile-user

Thien-Thi Nguyen <ttn@glug.org> writes:

>    From: Neil Jerram <neil@ossau.uklinux.net>
>    Date: Sun, 30 Oct 2005 22:59:32 +0000
>
>    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, someone will want to change it to be more permissive in future?
>
> both interpretations are fine.

Yes, but which one did you mean?  It seems to me that they have
opposite implications.

>    perlis?
>
> google?

Fair point.

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  1 sibling, 1 reply; 55+ messages in thread
From: Kevin Ryde @ 2005-10-31 23:54 UTC (permalink / raw)
  Cc: guile-user

Neil Jerram <neil@ossau.uklinux.net> 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 adding /usr/local
to the default path, and then leave it up to distros to patch if they
want further locations.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-31 19:20                   ` Neil Jerram
  2005-10-31 23:54                     ` Kevin Ryde
@ 2005-11-01 23:31                     ` Vorfeed Canal
  2005-11-12 17:54                       ` Neil Jerram
  1 sibling, 1 reply; 55+ messages in thread
From: Vorfeed Canal @ 2005-11-01 23:31 UTC (permalink / raw)


On 10/31/05, Neil Jerram <neil@ossau.uklinux.net> wrote:
> Kevin Ryde <user42@zip.com.au> 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)
>
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

Other reasons are still valid.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-30 18:04               ` Neil Jerram
                                   ` (2 preceding siblings ...)
  2005-10-30 23:48                 ` Kevin Ryde
@ 2005-11-02  8:44                 ` Ludovic Courtès
  2005-12-03 13:05                   ` Neil Jerram
  3 siblings, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-11-02  8:44 UTC (permalink / raw)
  Cc: guile-user

Hi,

Neil Jerram <neil@ossau.uklinux.net> 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 `init.d' approach looks very promising and simpler than the one
   before, which is good.

2. I'd let the files in the `init.d' directory do a
   `(require-load-path-directory ...)' rather than just containing the
   directory name.  A good reason for this is that it is anyway very
   easy to evaluate those files in a confined environment
   (e.g. `null-environment' + the `require-load-path-directory'
   binding).

3. I'm a bit concerned that this approach is not scalable: opening,
   reading, and evaluating say a dozen of files each time Guile is
   started may have a noticeable impact on startup time.

   Maybe those could be loaded lazily, for instance in
   `try-module-autoload', the first time `%search-load-path' fails.


Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-31 19:22                       ` Neil Jerram
@ 2005-11-08 12:37                         ` Thien-Thi Nguyen
  0 siblings, 0 replies; 55+ messages in thread
From: Thien-Thi Nguyen @ 2005-11-08 12:37 UTC (permalink / raw)
  Cc: guile-user

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: Mon, 31 Oct 2005 19:22:31 +0000

   > 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 is a signal to retreat (from a design pov) to safer ground.
perhaps that is not possible...

thi


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-10-31 23:54                     ` Kevin Ryde
@ 2005-11-12  9:47                       ` Neil Jerram
  0 siblings, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2005-11-12  9:47 UTC (permalink / raw)
  Cc: guile-user

Kevin Ryde <user42@zip.com.au> writes:

> Neil Jerram <neil@ossau.uklinux.net> 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 adding /usr/local
> to the default path, and then leave it up to distros to patch if they
> want further locations.

I initially thought this also - see
http://lists.gnu.org/archive/html/guile-devel/2004-11/msg00036.html.
But the consensus since then seems to be that we need something that
will work more automatically, for both distribution-managed and
non-distribution-managed packages being installed somewhere that isn't
already in the load-path.

What did you have in mind by "leave it up to distros to patch"?

    Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-11-01 23:31                     ` Vorfeed Canal
@ 2005-11-12 17:54                       ` Neil Jerram
  0 siblings, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2005-11-12 17:54 UTC (permalink / raw)
  Cc: Guile Users

Vorfeed Canal <vorfeed.canal@gmail.com> 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 only from W2K onwards, so not NT,
but that's probably enough to allow us to consider symlink solutions
if they are compelling enough in other respects.

Regards,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-11-02  8:44                 ` Ludovic Courtès
@ 2005-12-03 13:05                   ` Neil Jerram
  2005-12-13  8:38                     ` Ludovic Courtès
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2005-12-03 13:05 UTC (permalink / raw)


ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Neil Jerram <neil@ossau.uklinux.net> 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.  ;-)

Thanks.

> 1. Your `init.d' approach looks very promising and simpler than the one
>    before, which is good.
>
> 2. I'd let the files in the `init.d' directory do a
>    `(require-load-path-directory ...)' rather than just containing the
>    directory name.  A good reason for this is that it is anyway very
>    easy to evaluate those files in a confined environment
>    (e.g. `null-environment' + the `require-load-path-directory'
>    binding).

OK, but aren't (1) and (2) both a bit scuppered by ...

> 3. I'm a bit concerned that this approach is not scalable: opening,
>    reading, and evaluating say a dozen of files each time Guile is
>    started may have a noticeable impact on startup time.

I think you're right.  It makes sense to do something like this for a
long-lived program such as Emacs, or for programs whose interactive
performance is not a concern, such as ifup and cron.  But we'd like
(or at least I'd like) Guile to be used for even very quick scripts,
and it doesn't make sense to increase the start up time of such
scripts by unconditionally loading arbitrary startup code for whatever
other Guile packages are installed.

I think this rules out any kind of iteration through a .d directory
from init.scm.  Apologies for not seeing this consideration before.

>    Maybe those could be loaded lazily, for instance in
>    `try-module-autoload', the first time `%search-load-path' fails.

This would be OK if the package startup file contained only a load
path, and not arbitrary code.  If the startup file was allowed to
contain arbitrary code, that code would presumably be important for
the initialization of the package concerned.  But it would be skipped
if some other circumstance meant that the package's install location
was already in Guile's load path.

Therefore any load-failure-based mechanism for loading startup files
needs to restrict the format of the startup files to just load path
directories.  It also has two disadvantages in my opinion.  Firstly it
feels a bit magic/under the covers/non-deterministic, where I would
prefer something more explicit/deterministic.  Secondly it still has
to unnecessarily load the startup files of all Guile packages on the
system, because it has no way to map the file name or module that
couldn't be loaded to a particular package.

So here's yet another proposal.  We keep the idea of a package
installing a startup file in some directory under $sysconfdir, but we
don't do anything with these in init.scm.  We provide instead:

 -- Scheme Procedure: initialize-packages . package-names
     Load the startup file for each of the packages in PACKAGE-NAMES.
     The startup file for a given package is only loaded once per
     Guile run, so `initialize-packages' avoids loading a package's
     startup file again if it has already been loaded.
     If one of the named packages doesn't have a startup file,
     `initialize-packages' calls `package-startup-file-not-found'
     with the package name as the only argument.  By default
     `package-startup-file-not-found' prints a warning to standard
     output, but you can `set!' it to something else if that is
     more appropriate for your application.

The idea would be for both Guile applications and Guile modules to use
this.  A Guile application should know which packages it uses
(directly), and so can include an appropriate `initialize-packages'
call in its startup script.  Similarly a Guile module knows which
packages it uses, and so can call `initialize-packages' before trying
to use any modules from that package.

(In practice this would mean before the define-module form, but I
don't see anything wrong with that.  For example:

  (initialize-packages "guile-gtk")

  (define-module (ossau widgets)
    #:use-module (gtk gtk)
    ...)

)

I believe this scheme works equally well whether we allow the startup
file to contain arbitrary code, or we restrict it to contain just load
path directories.  If we chose to restrict it, we might want to rename
`initialize-packages' to something more precise, such as
`merge-package-load-paths'.

A possible benefit of the restricted format is that I think we could
write an autoconf macro (for configure.in) that would generate and
install the startup file completely automatically.  But perhaps we can
still do that anyway with the arbitrary code format, and allow it to
be overridden when the package has particular requirements.

So (once again!) please let me know your thoughts.  Is this at last
the answer?

Regards,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-12-03 13:05                   ` Neil Jerram
@ 2005-12-13  8:38                     ` Ludovic Courtès
  2005-12-16  0:16                       ` Neil Jerram
  0 siblings, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-12-13  8:38 UTC (permalink / raw)
  Cc: guile-user

Hi Neil,

Sorry for the delay in answering your proposal.

Neil Jerram <neil@ossau.uklinux.net> 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 my
500 MHz G4...

>  -- Scheme Procedure: initialize-packages . package-names
>      Load the startup file for each of the packages in PACKAGE-NAMES.
>      The startup file for a given package is only loaded once per
>      Guile run, so `initialize-packages' avoids loading a package's
>      startup file again if it has already been loaded.
>      If one of the named packages doesn't have a startup file,
>      `initialize-packages' calls `package-startup-file-not-found'
>      with the package name as the only argument.  By default
>      `package-startup-file-not-found' prints a warning to standard
>      output, but you can `set!' it to something else if that is
>      more appropriate for your application.
>
> The idea would be for both Guile applications and Guile modules to use
> this.  A Guile application should know which packages it uses
> (directly), and so can include an appropriate `initialize-packages'
> call in its startup script.  Similarly a Guile module knows which
> packages it uses, and so can call `initialize-packages' before trying
> to use any modules from that package.
>
> (In practice this would mean before the define-module form, but I
> don't see anything wrong with that.  For example:
>
>   (initialize-packages "guile-gtk")
>
>   (define-module (ossau widgets)
>     #:use-module (gtk gtk)
>     ...)
>
> )

Hmm, I don't like it a lot, I find it way too intrusive.  And this may
also have a slight impact on startup time.

Maybe we could instead go for an ad hoc solution.  For instance, have
Guile provide a `guile-setup' program which could be used as follows:

  $ guile-setup add-load-path "/usr/chbouib/guile/"
  $ guile-setup remove-load-path "/usr/local/share/guile/smurf"

In practice, this would modify a single (text) file, say,
`$data/load-paths.cfg'.  This very file would be loaded when Guile is
started, modifying `%load-path' accordingly.  Autoconf macros would make
sure that `guile-setup add-load-path' is called upon installation of a
Guile package.

For efficiency reason, this file should be text-only (e.g., one load
path per line), or it could be more Scheme-friendly (e.g., a sequence of
RnRS strings which may be read by `read').  It should not require any
call to `eval'.

What do you think?

This is certainly not perfect but I think we must strive (i) to keep
things simple and (ii) to avoid wasting more cycles.

Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  0 siblings, 2 replies; 55+ messages in thread
From: Neil Jerram @ 2005-12-16  0:16 UTC (permalink / raw)


ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Neil Jerram <neil@ossau.uklinux.net> 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 my
> 500 MHz G4...

Good, thanks.

>>  -- Scheme Procedure: initialize-packages . package-names [...]
>
> Hmm, I don't like it a lot, I find it way too intrusive.  And this may
> also have a slight impact on startup time.

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.

> Maybe we could instead go for an ad hoc solution.  For instance, have
> Guile provide a `guile-setup' program which could be used as follows:
>
>   $ guile-setup add-load-path "/usr/chbouib/guile/"
>   $ guile-setup remove-load-path "/usr/local/share/guile/smurf"
>
> In practice, this would modify a single (text) file, say,
> `$data/load-paths.cfg'.  This very file would be loaded when Guile is
> started, modifying `%load-path' accordingly.  Autoconf macros would make
> sure that `guile-setup add-load-path' is called upon installation of a
> Guile package.
>
> For efficiency reason, this file should be text-only (e.g., one load
> path per line), or it could be more Scheme-friendly (e.g., a sequence of
> RnRS strings which may be read by `read').  It should not require any
> call to `eval'.
>
> What do you think?

I proposed something very like this before:
http://lists.gnu.org/archive/html/guile-user/2005-10/msg00098.html
But then I changed my mind, for reasons given here:
http://lists.gnu.org/archive/html/guile-user/2005-10/msg00109.html

> This is certainly not perfect but I think we must strive (i) to keep
> things simple and (ii) to avoid wasting more cycles.

Sure, but simple is a complicated concept :-).  For example, the
initialize-packages approach is simple in that it doesn't require a
post-install script to work (whereas the config.scm approach does).

Things aren't clear cut in terms of cycles either.  Suppose you have
20 Guile packages installed on your computer, spread across 6
different load path locations.  With the config.scm approach you will
always have all 6 locations in your load path, even when running a
script that uses only one package (or no packages at all), so on
average it will take a little longer to load every file that the
script needs.  With the initialize-packages approach, the script's
load path will only contain the directories that it really needs.

Does that sway you at all?  Anyone else?

     Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-12-16  0:16                       ` Neil Jerram
@ 2005-12-16  1:00                         ` Neil Jerram
  2005-12-16  9:55                         ` Ludovic Courtès
  1 sibling, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2005-12-16  1:00 UTC (permalink / raw)


Neil Jerram <neil@ossau.uklinux.net> 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
%load-path), and that's bound to be useful sooner or later.

One example is the (gnome-0) module that guile-gnome installs in
/usr/share/guile/site, and which modifies %load-path (to point to the
rest of the install under /usr/share/guile-gnome-0) and
LD_LIBRARY_PATH.  This unusual arrangement prevented me from loading
guile-gnome at first, because I was using /usr/local/bin/guile, which
doesn't have /usr/share/guile/site in its load path.  If the stuff in
(gnome-0) was instead installed under /etc/guile/packages, it would
work in principle for both /usr/bin/guile and /usr/local/bin/guile.

Then, if we allow that guile-gnome has to munge LD_LIBRARY_PATH in
(gnome-0), i.e. outside of its main installed module tree, we have to
go with the initialize-packages approach.  In fact guile-gnome
_doesn't_ have to do this, so its not an open and shut case.  (It
could move the LD_LIBRARY_PATH code to a module in the main tree, and
make sure that this module is always used before any that depend on
LD_LIBRARY_PATH.)  But it makes sense to munge the load path and
LD_LIBRARY_PATH in the same place, so I'd say this is a good argument
for the initialize-packages approach and for allowing arbitrary code
execution.

Regards,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  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
  1 sibling, 1 reply; 55+ messages in thread
From: Ludovic Courtès @ 2005-12-16  9:55 UTC (permalink / raw)
  Cc: guile-user

Neil Jerram <neil@ossau.uklinux.net> 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.
It's quite a big change and it's very interpreter-centric (okay, this
last point is maybe not the strongest argument I could come up with
;-)).

It would be different if the `initialize-packages' line could be added
automatically --- in fact, `use-modules' could do it and this would be
completely transparent to the module user (more below).

Furthermore, other interpreters are less intrusive in that respect
AFAIK.

>From a performance viewpoint, you still end up reading _and evaluating_
one more file, thus increasing actual start-up time (because chances are
that 90% of the modules that will ever be loaded by a program are loaded
at start-up time).

> I proposed something very like this before:
> http://lists.gnu.org/archive/html/guile-user/2005-10/msg00098.html
> But then I changed my mind, for reasons given here:
> http://lists.gnu.org/archive/html/guile-user/2005-10/msg00109.html

I suspected this to have already been said.  Sorry for not looking it up
in the archive.

> Sure, but simple is a complicated concept :-).  For example, the
> initialize-packages approach is simple in that it doesn't require a
> post-install script to work (whereas the config.scm approach does).

Right.  But, well, as long as this is encapsulated in some Automake
machinery, it doesn't make a big difference.

> Things aren't clear cut in terms of cycles either.  Suppose you have
> 20 Guile packages installed on your computer, spread across 6
> different load path locations.  With the config.scm approach you will
> always have all 6 locations in your load path, even when running a
> script that uses only one package (or no packages at all), so on
> average it will take a little longer to load every file that the
> script needs.  With the initialize-packages approach, the script's
> load path will only contain the directories that it really needs.

Right.

But then, an intermediate approach could consist in having an `init.d'
directories where files cannot contain arbitrary code, i.e., they only
contain a string (the load path).

Additionally, I'd be quite happy if the `initialize-packages' phase
could be made automatic.  This could be done like this:

  1. Packages install their module hierarchy wherever they want;

  2. In addition, packages may install a start-up file in, say,
     /usr/share/guile/packages/ (installing these files into the right
     Guile directory could be done by a wrapper script, say
     `guile-install-module-init').

     For instance, if I am to install the complete `foo' module
     hierarchy, then I can install /usr/share/guile/packages/foo.init
     that will be read, if available, the first time a `(foo SOMETHING)'
     module is loaded.  If that file was available, its content (a
     string) are added to `%load-path'.


More generally, when module `(foo bar)' is loaded for the first time,
Guile could:

1. Look for /../packages/foo/bar.init and use its content to
   augment `%load-path' if available;

2. If the previous file wasn't available, look for
   /../packages/foo.init and use its content to augment
   `%load-path' if available;

3. If no `init' file was found, just leave `%load-path' unchanged.


This way, `init' files are loaded on demand, like in your
`initialize-packages' approach.  However, it is less intrusive.

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.

Not being able to execute arbitrary code in an init file is not a
problem: anyway, once an init file has been loaded, the module itself
can be loaded and execute whatever code it wants.

Note that I'm not addressing shared library load paths at all here.
However, such a mechanism could certainly be extended to support it.

Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2005-12-16  9:55                         ` Ludovic Courtès
@ 2006-01-07 13:37                           ` Neil Jerram
  2006-01-11  4:49                             ` steve tell
  0 siblings, 1 reply; 55+ messages in thread
From: Neil Jerram @ 2006-01-07 13:37 UTC (permalink / raw)


ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Neil Jerram <neil@ossau.uklinux.net> 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.
> It's quite a big change and it's very interpreter-centric (okay, this
> last point is maybe not the strongest argument I could come up with
> ;-)).

Fair point.  It would be better to avoid this if we could.

> It would be different if the `initialize-packages' line could be added
> automatically --- in fact, `use-modules' could do it and this would be
> completely transparent to the module user (more below).

 [...]

> Additionally, I'd be quite happy if the `initialize-packages' phase
> could be made automatic.  This could be done like this:
>
>   1. Packages install their module hierarchy wherever they want;
>
>   2. In addition, packages may install a start-up file in, say,
>      /usr/share/guile/packages/ (installing these files into the right
>      Guile directory could be done by a wrapper script, say
>      `guile-install-module-init').
>
>      For instance, if I am to install the complete `foo' module
>      hierarchy, then I can install /usr/share/guile/packages/foo.init
>      that will be read, if available, the first time a `(foo SOMETHING)'
>      module is loaded.  If that file was available, its content (a
>      string) are added to `%load-path'.
>
>
> More generally, when module `(foo bar)' is loaded for the first time,
> Guile could:
>
> 1. Look for /../packages/foo/bar.init and use its content to
>    augment `%load-path' if available;
>
> 2. If the previous file wasn't available, look for
>    /../packages/foo.init and use its content to augment
>    `%load-path' if available;
>
> 3. If no `init' file was found, just leave `%load-path' unchanged.
>
>
> This way, `init' files are loaded on demand, like in your
> `initialize-packages' approach.  However, it is less intrusive.
>
> 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 is all possible, but it feels to me quite complex and not very
elegant; it doesn't feel right to have a shadow tree of potentially
all installed modules under $sysconfdir.

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.

Regards,
        Neil



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


^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2006-01-07 13:37                           ` Neil Jerram
@ 2006-01-11  4:49                             ` steve tell
  2006-01-12 18:01                               ` Neil Jerram
  0 siblings, 1 reply; 55+ messages in thread
From: steve tell @ 2006-01-11  4:49 UTC (permalink / raw)
  Cc: guile-user

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3157 bytes --]



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:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Neil Jerram <neil@ossau.uklinux.net> 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

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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

^ permalink raw reply	[flat|nested] 55+ messages in thread

* Re: Modified load-path proposal
  2006-01-11  4:49                             ` steve tell
@ 2006-01-12 18:01                               ` Neil Jerram
  0 siblings, 0 replies; 55+ messages in thread
From: Neil Jerram @ 2006-01-12 18:01 UTC (permalink / raw)
  Cc: guile-user

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


^ permalink raw reply	[flat|nested] 55+ messages in thread

end of thread, other threads:[~2006-01-12 18:01 UTC | newest]

Thread overview: 55+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

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