[Ecls-list] ecl include and library directories

[Nils Bruin]

On Sun, 22 May 2011, Juan Jose Garcia-Ripoll wrote:

> ECL has two installation modes, one follows the Unix hierarchy
[...]
> the other one has everything in the same directory (Logical pathname 
> SYS:), as it is traditional in Windows.

Thank you for the explanation! That makes sense. So the "same-directory" 
detection in c::ecl-library-directory is imperfect, but that doesn't 
matter because the detection in c::ecl-include-directory is accurate and 
if the latter fails, the former is not important.

I agree that relocating with "everything in the same dir" makes more sense 
than with "unix hierarchy". It's just a Sage thing that essentially the 
location of what would normally be /usr/local can actually change. We 
could see if a "windows style install" of ECL inside the sage tree makes 
more sense. However, it seems to me that the paths to the initial location 
would still be hardcoded and that picking up the location after relocation 
would be dependent on the old resources being removed from that location 
(i.e., after a copy rather than a move, the headers in the old location 
would still be used)

The --with-init-form option sounds like the way to go once it makes it 
into an ECL release. Then we can ensure we're looking at the new location.

The mix of fixed paths for unix-style install and dynamic path 
determination for windows-style install could, in rare cases, lead to hard 
to find bugs. Consider the following (contrived) scenario:

  1. Someone does a unix-style install of ecl version N
  2. moves files to change to a flat install. Paths are still hardcoded, 
but since certain file-probes fail, ECL overwrites those with dynamically 
generated paths
  3. Someone does a unix-style install of ecl version M.
The ECL version N compiler still has hardcoded paths, that now point to 
version M. Since the file existence probes now succeed, the hardcoded 
paths take precedence and version N will try to compile against version M 
headers ...

Two alternative lessons:

  - Don't do step 2

  - Equipping an application both with hardcoded paths and with logic to 
dynamically locate resources can lead to the impression that an 
application is relocatable, but since it is still silently checking a now 
stale location for resources, it can be misled by someone elso putting 
similar resources in that stale location. That can lead to hard-to-find 
errors.