On 2008-09-03 17:23+0100 Andrew Ross wrote: > On Wed, Sep 03, 2008 at 07:58:01AM -0700, Alan Irwin wrote: >> I think a good compromise here is to use "ocamlc -where" results but with >> the >> install prefix substituted for the system prefix. IIRC, this is what we do >> in the python case where we also have to deal with versioned and >> distribution dependent install directories. >> >> The result would be $prefix/lib/ocaml/3.10.2 on Debian >> and $prefix/lib64/ocaml on Fedora so both sets of packagers get the >> right result automatically when $prefix is /usr, and users who want/need >> a non-root install prefix are allowed to have one. > > Alan, > > Sounds like a good potential compromise. This is easy on UNIX where there > is a default /usr prefix. How will this work on other platforms where we > don't necessarily know what the prefix is, or even for cases where ocaml > is installed in a non-standard location?
Well when I wrote the above I was thinking along the lines of a CMake regex to find lib.*/ocaml.* in the directory string and replace everything above that with the installation prefix. That would certainly work in the above two cases. I cannot guarantee it will work in all cases until we get more user feedback. Of course, there is also the alternative of creating a CMake option to install exactly in the location given by ocamlc -where. If you prefer that optional approach to the regex approach, that is fine with me. To answer your question about overriding cached variables versus uncached variables using -D options, my own opinion is that is problematic because I believe the behaviour changed somewhere late in the 2.4.x series or between 2.4.8 and 2.6.0, and I think the behaviour also depends on whether you provide a variable type to the the -D option or not. Therefore, I think we should deal with this issue explicitly rather than asking the user to override certain CMake variables with -D options. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
