[Ecls-list] Cannot set compiler flags for compile-file
ahefner at gmail.com
Fri Jan 15 18:53:37 UTC 2010
On Fri, Jan 15, 2010 at 3:09 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> You have set them indeed to the right values (I presume _after_ loading the
> compiler with (require 'cmp), otherwise it does not work).
With this hint, I figured out the problem I reported a few days ago
regarding compiler flags. It hadn't occurred to me that the compiler
wasn't always resident (I blissfully ignore those loading messages).
It's still necessary for me to do things like (eval (read-from-string
"c::*cc-flags")) to get at the symbol at runtime, but the desired hack
- loading the compiler and reloading changed sourcefiles at runtime -
now works. Very cool.
> Note that I have not provided or prepared infrastructure for relocating
> binaries of ECL in unices. It is just too complicated and it contradicts
> most users' expectations
Can you elaborate on what this means?
I attempted to produce a standalone executable on Linux for a friend
to test, with the assumption that I only needed to bundle libecl.so
with it and make sure LD_LIBRARY_PATH was configured accordingly, but
my quick attempt failed. On a machine without ECL installed, the
executable dies at startup, complaining about not finding ECLDIR, or
something like that, implying I have to ship around some subset of
/usr/local/lib/ecl-[version]/. This is very bad from a deployment
standpoint - I really want executables to run self-contained from one
directory. It isn't so important on Linux, but I feel it is critical
on Windows and OS X. Is this related to the quote above, or were you
referring to something else entirely? I've put porting my app to
Windows off longer than is wise - I hope I don't run into major
problems there. If it's just a matter of paths, I don't mind hacking
ECL up to make it work.
More information about the ecl-devel