Re: Modified load-path proposal
Hi, Greg Troxel <[EMAIL PROTECTED]> writes: > before deciding about tags and descriptions, I think we need to be > clearer on the semantics of these directories and why they'd be used. > Let me take a stab at it, and I'm sure I'll leave out other's use > cases. I don't think we should reason 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
Re: Socket API improvement, patch #6
Hi, Just a reminder about this socket patch, <[EMAIL PROTECTED]>. I got my copyright assignment form signed and approved so if this change looks reasonable to you, it can probably go in. Kevin? Thanks, Ludovic. ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: problems running guile
Shelagh Manton <[EMAIL PROTECTED]> writes: > ERROR: In procedure primitive-load-path: > ERROR: Unable to find file "ice-9/boot-9.scm" in load path Sounds like a %load-path problem. What do you get on your system for $ which guile and $ locate boot-9.scm and $ locate libguile ? Neil ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Modified load-path proposal
[EMAIL PROTECTED] (Ludovic Courtès) writes: > I don't think we should reason about installation directories in terms > of packaging-system-managed vs. human-managed installations. I think > the packaging system is just a special case of the "human-managed > installation". However, packaging 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 <[EMAIL PROTECTED]> ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: Modified load-path proposal
[EMAIL PROTECTED] (Ludovic Courtès) writes: > In fact, maybe we should just mimic Autoconf/Automake and the GNU > Standards[0] by (i) identifying exactly what the various installation > directories we care about are, (ii) ensuring that they can be configured > at installation-time, and (iii) make 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
Re: Modified load-path proposal
Greg Troxel <[EMAIL PROTECTED]> writes:
> before deciding about tags and descriptions, I think we need to be
> clearer on the semantics of these directories and why they'd be
> used. [...]
Greg, I'm sorry but I don't want to comment in detail on everything
you've said. In my view what you have 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
Re: Socket API improvement, patch #6
[EMAIL PROTECTED] (Ludovic Courtès) writes: > > I got my copyright assignment form signed and approved so if this > change looks reasonable to you, it can probably go in. Kevin? Then you're just waiting for the nod from Marius. :) ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: problems running guile
Shelagh Manton <[EMAIL PROTECTED]> writes: > On Mon, 2005-10-17 at 18:32 +0100, Neil Jerram wrote: >> Shelagh Manton <[EMAIL PROTECTED]> writes: >> >> > ERROR: In procedure primitive-load-path: >> > ERROR: Unable to find file "ice-9/boot-9.scm" in load path >> >> $ which guile > /usr/bin/guile >> and >> >> $ locate boot-9.scm > /usr/share/guile/1.6/ice-9/boot-9.scm > /var/packages/@lilypond.org/lilypond:2.7.12/backup/usr/share/guile/1.6/ice-9/boot-9.scm That all looks OK. What command exactly were you running when you saw the error above? (Sorry for not asking that earlier.) Neil ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
Re: problems running guile
On Mon, 17 Oct 2005 23:36:11 +0100, Neil Jerram wrote: > Shelagh Manton <[EMAIL PROTECTED]> writes: > >> On Mon, 2005-10-17 at 18:32 +0100, Neil Jerram wrote: >>> Shelagh Manton <[EMAIL PROTECTED]> writes: >>> >>> > ERROR: In procedure primitive-load-path: >>> > ERROR: Unable to find file "ice-9/boot-9.scm" in load path >>> >>> $ which guile >> /usr/bin/guile >>> and >>> >>> $ locate boot-9.scm >> /usr/share/guile/1.6/ice-9/boot-9.scm >> /var/packages/@lilypond.org/lilypond:2.7.12/backup/usr/share/guile/1.6/ice-9/boot-9.scm > > That all looks OK. What command exactly were you running when you saw > the error above? (Sorry for not asking that earlier.) > > Neil > Both gnucash and lilypond give the same result. However, I did resolve the problem, not through understanding, but through brute force and the use of apt. I uninstalled guile and reinstalled it. Updateing lilypond using the autopackager must have corrupted the previous installation of guile. This solved the problem, but of course I don't know how or why :) Shelagh ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
