Re: Compiled load path issues

[Andy Wingo <wingo@pobox.com>]

Hi Ludovic,

On Wed 21 Oct 2009 18:22, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Tue 20 Oct 2009 10:27, ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> In theory, we could interpret the ‘.go’ cookie and byte-swap things if
>>> needed...
>>
>> In theory yes. In practice we map things read-only so they can be cached
>> and not copied, and we'd have to instrument individual VM ops
>
> Or we could copy the bytecode (when it’s foreign) instead of mmapping
> it, and translate instructions that are endianness-sensitive.
>
> Now, I agree it’s a big task, and one I’d rather avoid 2 months before
> 2.0.

I agree. (I'd rather avoid it altogether.)

>>> I’m in favor of ‘.go’ alongside ‘.scm’: that’s what happens with
>>> .elc/.el and .pyc/.py and it had been the plan from 1.9.0 until
>>> recently.
>>
>> For python, pyc files are in $libdir, for exactly this reason.
>
> Out of curiosity, are .pyc endianness- and word-size-sensitive?

I think so, yes. I could be wrong.

> What about .elc?

Don't know.

> Guile itself currently installs ‘.go’ under $pkgdatadir.  That would
> need to be changed to $pkglibdir/1.9, right?

.scm files got to $pkgdatadir, .go files to $pkglibdir.

> Also we now have $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH.  Should
> we also have an equivalent to ‘-L’?

Hm, good question. I don't know the answer to that one.

Regards,

Andy
-- 
http://wingolog.org/