<div class="gmail_quote">On Fri, Jan 15, 2010 at 7:53 PM, Andy Hefner <span dir="ltr"><<a href="mailto:ahefner@gmail.com" target="_blank">ahefner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>With this hint, I figured out the problem I reported a few days ago</div>
regarding compiler flags. It hadn't occurred to me that the compiler<br>
wasn't always resident (I blissfully ignore those loading messages).<br>
It's still necessary for me to do things like (eval (read-from-string<br>
"c::*cc-flags")) to get at the symbol at runtime, but the desired hack<br>
- loading the compiler and reloading changed sourcefiles at runtime -<br>
now works. Very cool.<br></blockquote><div><br></div><div>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.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> Note that I have not provided or prepared infrastructure for relocating<br>
> binaries of ECL in unices. It is just too complicated and it contradicts<br>
> most users' expectations<br>
<br>
</div>Can you elaborate on what this means?<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I attempted to produce a standalone executable on Linux for a friend<br>
to test, with the assumption that I only needed to bundle libecl.so<br>
with it and make sure LD_LIBRARY_PATH was configured accordingly, but<br>
my quick attempt failed. On a machine without ECL installed, the<br>
executable dies at startup, complaining about not finding ECLDIR, or<br>
something like that, implying I have to ship around some subset of<br>
/usr/local/lib/ecl-[version]/. This is very bad from a deployment<br>
standpoint - I really want executables to run self-contained from one<br>
directory.</blockquote><div><br></div><div>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</div>
<div>- the hardcoded directory</div><div>- a directory chosen by the ECLDIR environment variable</div><div>- the current directory</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It isn't so important on Linux, but I feel it is critical<br>
on Windows and OS X. Is this related to the quote above, or were you<br>
referring to something else entirely? I've put porting my app to<br>
Windows off longer than is wise - I hope I don't run into major<br>
problems there. If it's just a matter of paths, I don't mind hacking<br>
ECL up to make it work.<br>
</blockquote></div><div><br></div>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. <div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Juanjo<br><div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>
</div></div>