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