Hey, Andy Wingo <wi...@pobox.com> writes:
> Oftentimes you would > want to be able to map a .go file to a corresponding .scm, and currently > it's difficult. For example if you compile in a +build subdirectory of > Guile via `../configure', then the `port-filename' is e.g. > "../../module/ice-9/boot-9.scm", which doesn't make any sense. Likewise, this caused problems for coverage testing, where relative paths weren’t correctly interpreted by LCOV, hence this change to embed absolute paths: <http://git.sv.gnu.org/cgit/guile.git/commit/?h=wip-coverage&id=873e4d69a08a9ceb2a7a0296130b6a884738324f>. > One could instead embed the absolute path, but then you have the problem > that you might remove your build or source directory; it doesn't make > sense to have installed files pointing to build paths. DWARF does this, > but only because with C you don't install the source, but with Guile you > should. Both good points! (This obviously invalidates the absolute path change above.) > So for me the right thing to do, by default, is to embed a path relative > to the `%load-path', so that one can find the source file via something > like: > > (use-modules (system vm program)) > (define (program-source-file p) > (search-path %load-path (source:file (program-source p 0)))) OK, though that’s unavoidably ambiguous: ‘%load-path’ could be different than its compile-time value, etc. > I added a keyword argument to compile-file and compile-and-load for this > purpose, OK. > to parameterize %file-port-name-canonicalization during the extent of > the given file's compilation. As noted in the other thread, I’d rather get rid of this fluid and have ‘compile’ & co. call ‘canonicalize-path’. Thanks, Ludo’.
