[asdf-devel] the same (asdf::implementation-identifier) for byte-compiler and lisp-to-C-compiler of ECL

[Faré]

On Sun, Jan 15, 2012 at 03:54, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> ECL offers two compiles: byte-compiler and lisp-to-C compiler.
>
> They produce incompatible .fasls
>
At least in a recent ECL (I tested with a git checkout from November
2011), they also should be using different extensions, .fas for the
usual compiler, and .fasc for the bytecode compiler. Is there somehow
a clash on windows because these share the same first three
characters?

> (asdf::implementation-identifier) does not accounts the difference and
> returns the same value - ecl-11.1.1-win-x86.
>
I could include a bytecode indicator in there, but you'd have to
explicitly asdf::clear-output-translations when you switch compiler.

> As implementation-identifier is used to compute output files location,
> the same file location is used to store .fasls of both ECL compilers
>
> (in my case C:\Users\anton\AppData\Roaming\common-lisp\cache\ecl-11.1.1-win-x86\).
>
I'm a bit surprised that LOCALAPPDATA includes Roaming\ instead of
Local\ but then again I don't understand Windows paths very well. If
you think that's wrong, please suggest a better heuristic for choosing
a path to the cache.

> In result, if some files are compiled with byte-compiler, and latter user
> tries the lisp-to-C-compiler, he has errors during .fasl load.
>
Shouldn't the different pathname type prevent such an issue? Are there
more subtle issues due to e.g. different API in generated FFI .so
files?

I'll withhold the releasing of ASDF 2.20 until this issue is resolved.

Regards,

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Judge and party — the ultimate nature of a monopoly government.