[Ecls-list] Cannot set compiler flags for compile-file

[Andy Hefner]

On Sat, Jan 16, 2010 at 3:26 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:

> I do not understand why you need the read-from-string if you use (REQUIRE
> 'CMP) at your ~/.ecl or ~/.eclrc file before changing the settings.

I'll try to explain, in case it's ever useful. First, the problem only
occurs in compiled executables, where code has been compiled in that
refers to the C package, such that you've had to (require 'cmp) at
runtime to load the compiler. The compiled code refers to
C::*CC-FLAGS*, but before you do (require 'cmp), the C package doesn't
exist at all. (read-from-string "'c::*cc-flags*") will fail with a
package error, and reading c::*cc-flags* fails as an unbound variable.
When the compiler is loaded, it appears to create the C package and
the symbols within it, but these aren't unified with references to
these symbols in the compiled code. At this point, previously compiled
code that reads c::*cc-flags* still errs with an unbound variable
error, yet (symbol-value (read-from-string "c::*cc-flags*")) now
returns ECL's default compiler flags. The assertion (eq 'c::*cc-flags*
(read-from-string "c::*cc-flags*")) fails from code compiled into the
executable, even after the compiler is loaded. Likewise, (assert (eq
(symbol-package 'c::*cc-flags*) (symbol-package (read-from-string
"c::*cc-flags*")))) fails.

I don't claim this is a bug. It seems logical, in the same way that
you can't load a system at runtime and expect to call it directly in
your code without getting package errors. The existence of a
(different) C package at compile time just obscures the problem
somewhat - now code referencing that package compiles fine, but the C
package created at runtime is not the same package that existed when
the code was compiled.


> First of all, there is all I mentioned before about ECLDIR, hardcoding and
> also being able to change the value of the directory at run time. Second, in
> Windows we can find the system directory because programs are installed
> differently: ecl.exe, ecl.dll and the ECL's internal files (ucd.dat,
> help.doc, etc) have to be in the same directory and this is told to us by
> Windows' system functions.

Thanks for the information.