Re: file names embedded in .go

[ludo@gnu.org (Ludovic Courtès)]

Hey,

Andy Wingo <wingo@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’.