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. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ecls-list
