On Sun 18 Oct 2009 17:36, l...@gnu.org (Ludovic Courtès) writes: > Once upon a time, if ‘chbouib.go’ is in the vicinity of ‘chbouib.scm’, > then ‘(use-modules (chbouib))’ would load ‘chbouib.go’. This is no > longer the case, but can be remedied with something like this: > > diff --git a/libguile/load.c b/libguile/load.c > index 50af256..194d1e5 100644 > --- a/libguile/load.c > +++ b/libguile/load.c > @@ -726,7 +726,9 @@ SCM_DEFINE (scm_primitive_load_path, > "primitive-load-path", 0, 0, 1, > exception_on_not_found = SCM_BOOL_T; > > full_filename = scm_sys_search_load_path (filename); > - compiled_filename = scm_search_path (*scm_loc_load_compiled_path, > + compiled_filename = scm_search_path (scm_append > + (scm_list_2 > (*scm_loc_load_compiled_path, > + *scm_loc_load_path)), > filename, > *scm_loc_load_compiled_extensions, > SCM_BOOL_T); > > Andy: can you comment? What was the idea behind > ‘%load-compiled-path’?
The idea is that given that the compiled files are architecture-dependent, that they should go in $libdir instead of $datadir. We can add $libdir, but I don't think it's a good idea -- not only for reasons of excessive stat, but because I don't think we should be putting binaries in with installed source. > Besides, ‘scm_search_path ()’ was changed incompatibly compared to 1.8 > in 22f4ee48822db5e30df3abf9a11b6066f2bab9d3. I’m wary about such > incompatibilities and would like it if we could (1) list them, and > (2) avoid them unless we really really can’t think of any other way. In > this particular case, do you have an idea on how to avoid it? I don't really know. I'm sure it could be worked around somehow, but it's not very fun work. Andy -- http://wingolog.org/
