The following problem arises with ECL as packaged within Sage. Sage comes 
with essentially its own $SAGE_ROOT/usr/local/ tree and tries to ensure 
that the whole install directory of sage can be moved and that sage still 
runs OK in the new location.

This works for most of ECL, but not for its compiler. The reason is that 
the variables cc:*ecl-library-directory* and cc:*ecl-include-directory* 
get assigned default values at ECL build time. They normally point to 
usr/local/lib and usr/local/include, which one would normally expect to 
remain in the same place. However, in sage they might not do that. My 
questions:

  1. Is there already an option to set something in the run-time 
environment so that "vanilla" ecl picks up updated values for these paths?
The standard build script for maxima runs "ecl -norc" so ~/.eclrc is not 
an option. Wrapping the ecl executable with a script that prepends some 
"-eval" lines does work, but perhaps there are better options.

  2. The variables cc::*cc-flags* and cc::*ld-flags* seem to be picking up 
an "-I..." and an "-L..." themselves in Sage's configuration. Is that 
normal (i.e., does that always happen)? Is it intentional?

  3. What would be the right spot to patch ECL so that the default values 
for these paths are constructed at runtime? The kind of value I am looking 
for is:

(setf c::*ecl-include-directory* (concatenate 'string (SI:GETENV "SAGE_ROOT") 
"/local/include/"))

Given the value given by

(namestring (translate-logical-pathname "SYS:"))

it actually looks like ECL would be able to get close to the right path by 
itself.

For reference, the sage trac for this issue is

http://trac.sagemath.org/sage_trac/ticket/11359

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Reply via email to