[Ecls-list] ecl include and library directories
nbruin at cecm.sfu.ca
Sun May 22 22:44:20 UTC 2011
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
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
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
More information about the ecl-devel