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

[Juan Jose Garcia-Ripoll]

On Fri, Jan 15, 2010 at 7:53 PM, Andy Hefner <ahefner at gmail.com> wrote:

> 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.
>

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.


> > 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?
>

This does not mean what you are reporting in the next paragraph. It means
that if you build ECL to install it in a certain path, as per ./configure
--prefix=...  then it is not supported to install it elsewhere.


> 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.


Part of this was due to a bug in ECL's startup routines. They should not
abort when they can not find the system directory which you could change
using the ECLDIR environment variable, by the way. I have committed a fix
that changes the default value, when the hard coded one does not exist, to
the current directory. Note however that it is not always possible to just
ship the library file: if you use Unicode also the file ucd.dat has to be
shipped and be accessible in either
- the hardcoded directory
- a directory chosen by the ECLDIR environment variable
- the current 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.
>

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.

Next, in OS X files and programs can and should be installed "the Unix way",
with precise locations to find things. This is ok for "perl", "python" and
most other software that comes with the operating system. Applications seem
to work differently but this is not true: files are bundled inside the *.app
directory and typically programs such as Matlab have wrappers, scripts that
call the actual binaries that are bundled there telling them where to find
their system directories. One such scripts for instance could set up a
proper value for ECLDIR.

Finally, what the original poster wanted to do is a completely different
thing than what has been discussed here. ECL was configured by the package
builder to be found in a precise location, /usr/pkg ... and this makes it
difficult to move it elsewhere. Maybe it is not impossible, but it is
already complicated enough to avoid it.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100115/d56d135f/attachment.html>