Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Well, in the big picture of Guile package development, both of these
> concepts could be useful. If I'm understanding you correctly, I would
> make the analogies that
>
> - a .la file is a bit like a formal list of all a package's
> dependencies (which in practice might have to be declared by the
> package author, or could be detected automatically by code analysis)
>
> - ld.so.conf is the environment information needed to be able to load
> all those dependencies, which is distilled from the .la file.
Right.
> I'm imagining that the distillation process may take some time - in
> the worst case, for example, it could require searching the whole file
> system - and so it makes sense to do it once at package installation
> time and cache the ld.so.conf-like results. I'm currently thinking of
> those results as just %load-path components, but they could (and
> probably should) be extended in future to cover LD_LIBRARY_PATH and/or
> the LTDL search path, for loading .so's.
>
> Overall, therefore, I'd say this idea is more about the ld.so.conf
> than about the .la files. Perhaps with this expanded explanation
> you'd now agree?
I don't see `.la' files as a cache of `ld.so.conf'. Libtool's `.la'
files are only used at compile-time, in order to find out library
dependencies, while `ld.so.conf' is used to locate dynamic libraries at
run-time, in a way similar to `%load-path'.
A dependency cache in Guile would make it possible to bypass
`%load-path'. I.e., instead of `(load-from-path "some-file.scm")',
which needs to go through `%load-path', it would allow the right file to
be directly loaded as in `(load "/some/path/some-file.scm")'. IOW, this
would be an /optimization/.
Personally, I don't think this optimization is worth it (more below).
> Those are both true, but in my mind (at least) there was one more
> factor, namely that it is not neat for every Guile application to
> start up with a load path that covers all installed Guile packages.
> It feels neater to me if each Guile application runs with exactly the
> environment that it needs.
You gave several good arguments against try to minimize `%load-path'.
In fact, I think that the optimization that consists of
minimizing/bypassing `%load-path' is not very valuable:
1. Practically, it seems that traversing even tens of directories to
locate a file is cheap compared to actually evaluating code, and, for
instance, marking and sweeping; ;-)
2. Just like `$PATH', `$LD_LIBRARY_PATH' and the likes, `%load-path'
should is not supposed to contain a lot of directories; currently, it
contains 4 items by default, and I guess people will rarely have more
than 10 items in it.
For the record, in Debian, most (if not all) Python packages get
installed in `/usr/lib/pythonX.X' and
`/usr/lib/pythonX.X/site-packages'. The same goes for Perl, etc.
As a conclusion, I'd still be in favor of a single file like this:
>> Or what about a single init file (again without any code, only data),
>> somewhat enhanced to keep track of which package rely on a each
>> particular load path:
>>
>> ((guile-gnome . "/opt/guile-gnome/")
>> (guile-chbouib . "/usr/local/share/guile-chbouib")
>> ... )
At startup-time, Guile would simply:
(set! %load-path
(append (map cdr (with-input-from-file "config.scm" read))
%load-path))
Actually, it's likely that several packages will rely on the same load
path, the format should rather be:
(((guile-gnome) . "/opt/guile-gnome")
((guile-chbouib guile-foo guile-bar) . "/usr/local/share/guile")
... )
Then, we need a `guile-update-load-path' script that does the right
thing with this file at (un)installation-time.
Thanks,
Ludovic.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
