On Sun, Jan 15, 2012 at 03:54, Anton Vodonosov avodonosov@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.