On Sun, May 22, 2011 at 10:28 AM, Nils Bruin <span dir="ltr"><<a href="mailto:nbruin@cecm.sfu.ca">nbruin@cecm.sfu.ca</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I am having some trouble with figuring out the default choices of the<br>
values of some of the paths used by the ECL compiler.<br clear="all"></blockquote></div><br>I am sorry you had to waste some time with this because of my late answer.<br><br>ECL has two installation modes, one follows the Unix hierarchy with /usr/include, /usr/lib, etc, the other one has everything in the same directory (Logical pathname SYS:), as it is traditional in Windows.<br>

<br>In short, the Unix mode<br><br>${prefix}/bin/ecl -> executable<br>${libdir} = ${prefix}/lib -> shared library<br>${libdir}/ecl-##.#.# -> ECL's private files<br>${includedir}/ecl = ${prefix}/include/ecl -> ECL's headers<br>

<br>The relocatable mode<br><br>${prefix}/ecl.exe -> executable<br>${prefix}/ecl/ -> include dir<br>${prefix}/ -> shared libraries<br>${prefix}/ -> ECL's private files<br><br>The first approach is fixed, hardcoded paths, the second one is the only one in ECL that allows relocation: it finds its executable file and from there it can compute all the rest.<br>

<br>ECL's current logic is designed to detect which of the two is the one we are using, while you were trying to get a mixture of both: do relocation while preserving some Unix structure _outside_ ECL's world. I never felt this was the right approach, since to me relocation is associated to being self-contained. However, feel free to work along this direction if you wish.<br>

<br>Cheers,<br><br>Juanjo<br><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>